It occurred to me that it might be useful to have declarative,
enforceable security policy in the server based the client's IP address
zone, where zones might be defined as internal (behind a firewall), DMZ,
VPN, external, or whatever. The policy might dictate what the client
*must* use for session encryption -- none, RC4, AES128, AES256,
something else, or no access at all. Analogous to the initial connect
protocol, the server would give the client a choice of encryption
schemes and let the client pick one, perhaps based on a user parameter.
The client, of course, couldn't connect with anything other than his
give list. This would let security default within the firewall to no
encryption while requiring clients in an external zone to use a robust
-- but expensive -- session encryption.

Another useful and easy to implement feature would be to restrict
capabilities based on zone and/or encryption level. Roman Simakov's
excellent point of setting passwords as weak link could be addressed by
a security policy that says that user administration must take place
over an encrypted linked, even if the client node lies within the
internal zone. It also could be used to say that user administration
could *only* be done from an internal zone.

This is another argument for Firebird to handle its own security rather
than requiring users to become system integrators.

And, incidentally, having following many of the quite useful links in
recent posts, I'm inclining towards defaulting encryption to RC4 rather
than AES-X based performance alone. RC4 may be less secure, but a
faster, less secure encryption that is used is vastly more secure than a
more secure algorithm that isn't. And yes, I am aware that the initial
stream bytes contain information about the key and must be discarded.

--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376