----- Original Message -----
From: "Jim Starkey" <jas@...>
Sent: Thursday, January 11, 2001 9:24 PM
Subject: Re: [IB-Architect] The Borland Back Door
> At 10:42 AM 1/12/01 +1100, Geoff Worboys wrote:
> >An estimate I read recently said that a Zip file encrypted with a 7
> >character password using only lowercase alphabetic characters
> >('a'..'z') could be cracked in 1.1 hours using a simple brute force
> >algorithm! Wordlists and other advancements can break weak keys even
> Having just witnessed a screw-up of historical proportions (hard to
> imagine a future book on open source without a chapter on
> Interbase/Borland), let try to not get too silly on the security
You're probably right. I know I'd add such a chapter. :-(
> The principles I think we need to adopt include these:
> 1. Implement nothing with a known hole; security by
> obscurity is out.
I've read it time and again written by some of the best people in
Cryptography and security: Those who don't show you the code have something
to hide. Generally, a bad implementation.
> 2. For each piece, pick the best available technology,
> even if that piece isn't the weakest link. Crypt()
> is bad; SHA or MD5 are good. Better than SHA or MD5,
> for firebird, is overkill. DES on passwords is bad;
SHA and MD5 are good. I personally use SHA, but for no particular reason.
> DES for single session line encryption is probably
> good enough. A better legal alternative would be
> worth considering.
As I suggested yesterday or the day before, both blowfish and twofish are
free and have no patents. Their author has commited to keeping them that
way. TwoFish was one of the AES finalists and stood all tests. BlowFish is
older but has no known weeknesses.
> 3. Don't get silly. If the server needs a PKI key pair,
> let it generate one. Requiring a certificate is
> a burden and is unnecessary.
> 4. Work at the weakest link. Encrypting passwords on the
> wire is good and we should do it, but unprotected system
> tables are a bigger threat than an a packet sniffer.
Interbase should encrypt not only passwords but data that goes over the wire
too. Preferably, the session password should changed every few minutes,
encrypted by an assymetric key pair. This means that both the server and
the client need key pairs. Certificate files are a standard place to put
the public keys. It may be that it is better to use a standard
implementation than to invent a new one.
> 5. Security logging is vital. Security software should
> detect a persistent threat and call for help. Returning
> an error 2^^55 times is rather dumb.
> 6. Don't force the user to be insecure. Virtually forcing
> uses to put account/passwords in environmental variables
> is nearly as bad as the back door. We need to come up
> with schema usable by humans.
When I saw that for the first time Icouldn't believe that someone hat
actualy implemented something like it and still though of calling it
> 7. Be creative and open minded. Static passwords are centuries
> old and have never worked very well. We've got storage,
> cpu, and brains. Let's use them all. Account -> challenge
> -> response is a vastly more secure paradigm.
> 8. Be rational about the threats. The biggest threat are our
> funbling fingers. More data has been destroyed by
> "delete from xxx" "oops" than deliberate "delete rdb$pages".
> The second biggest threat is disgruntled ex- or soon to be
> ex-employees. Third is the joy riding hacker. The spook
> services and intergalatic criminal geniuses fall way down
> the list (besides, if you make the system too hard to crack,
> they'll just shoot you).
> 9. Stay within the law if convenient. Export of strong
> encryption is still a problem for kit makers. Everybody
> but Congress knows there are no secrets, but Congress
> pays the FBI, et al. Try and make encryption configurable
> for the poor souls in countries that outlaw encryption.
> Don't violate patents, particularly since the RSA PKI
> patent as expired.
RSA seems like the best alternative, now. There are dozen of
implementations around, these days.
There are several tried free/open souce kits available such as OpenSSL.
> We know have the dubious pleasure of supporting the world's
> most notorious insecure relational database management system.
> Be better be prepared to show the world how it should be done.
At least try to have something in place that is not embarancing...