Check out the cover of today's New York Time's Sunday Magazine:
http://www.nytimes.com/pages/magazine/index.html

It's a packet sniffer. With less than a dozen lines of additional code
(small enough for the overleaf), it could pick up and report Firebird
login credentials with 100% certainty and 100% accuracy.

Firebird has two security problems. The little one is the persistent
request to encrypt databases at rest. The big one is the authentication
system that isn't even a tiny bit secure.

There are two approaches to these problems. The most most discussed is
to ignore them -- let somebody else worry about. Geoff and others have
worked long and hard find reasons that Firebird shouldn't or can't
address the problems. That's bunk. The other approach is to fix it.

Fixing Firebird security isn't as simple as supporting encryption
plugins because plugins can't address the key distribution problem.
Addressing the problem requires changes to the client, the protocol, and
the server. Complicating the solution is the honorable tradition of
allowing older clients to communicate with newer servers and vice versa.

The only responsible path is to propose, critique, and evolve a security
architecture until there is consensus that it is good enough, then
devise a strategy to implement it.

I'm going to describe the security architecture I'm using in NimbusDB as
a starting point. The key element is that clients generate one-time
session keys that are securely transmitted to server. Whether the key
only encrypts authentication credentials, all communications, or the
database file at page level can be discussed separately.

Here is the architecture:

1. Servers generate RSA key pairs at startup time. They may, if they
wish, generate new key pairs anytime they wish.
2. On first connection to a server, the client is given the server's
public key and a list of supported encryption algorithms.
3. The client selects an algorithm, generates a one-time session key
using a secure random number generator, encrypts the algorithm
type and session key using the server's public key, and sends the
gook to the server
4. The server decrypts the gook with its private key.
5. Passwords are stored in the database as SHA-1 hashes

At the moment, the algorithms supported are RC4, AES-128, and AES-256.
I have not built in support for certificates, but as all initial
connection messages are XML, adding them would be trivial. RSA is
hardwired. The default RSA keysize is 1024 bits, but this is
non-architectural and could be changed or made an option. I may switch
over to the MySQL strategy of sending the SHA-1 hash of the SHA-1 hash
of the password concatenated with a server supplied value.

Line protocol consists of four byte message lengths followed by
encrypted gook, rounded up to a multiple of the encryption algorithm's
blocksize. Encrypted gook embedded in character data is encoded in base64.

Guys, this is not plugin stuff.

On 11/14/2010 12:30 AM, Geoff Worboys wrote:
> Jim Starkey wrote:
>> It's getting a little annoying to hear you say we don't
>> know anything. The antidote to ignorance is to learn
>> something.
> Yes ... Is this some sort of progress we're making here, Jim?
> I mean not that long ago you seemed to suggest that you didn't
> need to know anything special or extra to use cryptography.
>
>
>> No, the WEP guys didn't fail to do their homework. When they
>> designed the system, it wasn't understood that a) the first
>> few bytes revealed a tiny bit about the key and b) knowing
>> the progression of generated keys allowed this to be exploited.
> That reads an awful lot like a contraction in terms, and
> there was more to it. This article gives one cryptographer's
> view: http://www.schneier.com/crypto-gram-0103.html#10
>
> And WEP are not the only ones to get it wrong, some manage to
> do even worse:
> http://www.schneier.com/blog/archives/2005/01/microsoft_rc4_f.html
>
> These are simply examples of people that thought they could
> implement a secure system based only on their own knowledge
> and the ready availability of some library functions. With
> a bit of luck those people may know better now.
>
>
>> [...]
>> So, if you have something to say, say it. If you have a
>> comment, a question, an objection, or a suggestion, we're
>> all ears. In specific, if there is something about Firebird
>> requirements or communication mechanisms, ask. I don't
>> think the requirements are at all settled, so that's a good
>> place to start, if you'd like to do something constructive.
> I've said most of it before so I'll try to be brief:
>
> * I'm not the one to listen to for technical details about
> secure protocols. Neither, I would suggest, are you, Jim.
>
> * To get the best possible result I suggest that you choose
> one of:
>
> A. Implement (or make it easier for the end-developer to
> implement) via existing and well tested protocol(s)
> (OpenSSL etc) - rather than trying to design your own.
>
> OR - if you feel you really have to design your own -
>
> B. Get help from _qualified_ sources. Either in person
> (perhaps someone from another open source project would
> agree to help out) with the initial design stages at least.
> Failing that, or in addition to that, whoever is going to
> write the code should research up-to-date references on
> the subject. This: http://www.schneier.com/book-ce.html
> is one example, there are others.
>
>
> Personally I like option A:
>
> . I think it offers the best opportunity for strong security
> that users can feel confident in (can choose from options
> where the entire protocol, not just the cipher algorithm,
> has been well studied).
>
> . Done well it should still allow developers to choose other
> options if they have specific needs. (It may be necessary
> for licence reasons etc.)
>
> . The responsibility for identifying and fixing often complex
> security vulnerabilities can fall to those with the
> knowledge, Firebird can just take up the changes.
>
> . Firebird should concentrate its resources on what it does
> best, if it can off-load the work involved in this far from
> trivial area then it should do so.
>
> . By implementing in terms of a larger external protocol you
> force the database code to remain independent of the
> security protocol. The risk with designing and embedding
> your own protocol within the database code is for one to
> begin to effect the other ... and so for vulnerabilities to
> be introduced by others that don't understand the reasons
> for certain behaviour. (Obviously most designs would try
> to avoid such inter-dependency but a completely separate
> protocol package would enforce it.)
>



[Non-text portions of this message have been removed]