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
>faster.
>

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
issues.

The principles I think we need to adopt include these:

1. Implement nothing with a known hole; security by
obscurity is out.

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;
DES for single session line encryption is probably
good enough. A better legal alternative would be
worth considering.

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.

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.

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.

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.


Jim Starkey