At 11:42 AM 5/28/99 -0400, Arnold G. Reinhold presented his
"top 10" common bad security practices. Generally good advice,
but I've pulled #3 for amendment:
> 3. Use of short passwords or weak passphrases to protect private keys or,
> worse, using them to generate symmetric keys. Bad passphrase advice
> abounds. For example, both Netscape and Microsoft advise using short
> passwords to protect private keys stored by their browsers. The simple fix
> is to use randomly generated passphrases of sufficient length. See
> http://www.hayom.com/diceware.html.
Nothing against diceware, but you must admit that there are some
excellent ways to use even *short* passwords to protect private keys.
Obvious examples include password-enabled smart-card storage,
and my favorite, password-authenticated access to remote storage.
Here's a revision that better focuses on those bad ways:
3. Use of short passwords or weak passphrases in an
irresponsible manner, such as directly encrypting a
private key. For example, both Netscape and Microsoft
advise using short passwords to encrypt private keys
stored by their browsers.
The rest sounds fine to me:
>1. Keys that are too short: Anything less than 80 bits for symmetric
>ciphers (128-bits prefered), or 1024 bits for integer-based public key
>systems. In particular this precludes use of 56-bit DES. (112-bit 3DES is
>fine.)
>
>2. Poor quality random number generation. Random quantities are needed at
>many places in the operation of a modern cryptographic security system. If
>the source of randomness is weak, the entire system can be compromised.
>
>3. [see revision above]
>
>4. Re-use of the same key with a stream cipher. I have seen this done many
>times with RC4. Even Microsoft appears to have gotten this wrong with
>their VPN (I do not know if it has been fixed). There are simple techniques
>to avoid this problem but they are often ignored. See
>http://ciphersaber.gurus.com for one method. The potential for slipping up
>in stream cipher implimentation makes a strong case for using modern block
>ciphers wherever possible.
>
>5. Using systems based on encryption techniques that have not been
>publically disclosed and reviewed. There are more than enough ciphers and
>public key systems out there that have undergone public scrutiny. Many of
>the best are now in the public domain: 3DES, Blowfish, Skipjack, Arcfour,
>D-H, DSA. Others, e.g. RSA, IDEA can be licensed.
>
>6. Ignoring physical security requirements for high value keys. In
>particular, no secret key is safe if it is used on a personal computer to
>which someone who is not trusted can gain physical access.
>
>7. Lack of thorough configuration management for cryptographic software.
>The best software in the world won't protect you if you cannot guarantee
>that the version you approved is the version being executed.
>
>8. Poor human interface design. Cryptographic systems that are too hard to
>use will be ignored, sabotaged or bypassed. Training helps, but cannot
>overcome a bad design.
>
>9. Failure to motivate key employees. Action or inaction, deliberate of
>inadvertent, by trusted individuals can render any security system worse
>than worthless. David Kahn once commented that no nation's communications
>are safe as long as their code clerks are at the bottom of the pay scale.
>
>10. Listening to salesmen. Any company that is selling cryptographic
>products has a good story for why the holes in their product really do not
>matter. Make sure the system you deploy is reviewed by independent experts.
I'm also amused that the one place where you slipped up
a tiny bit is in your own "sales pitch" for diceware.
A curious thing. :-)
Best regards,
David Jablon
[EMAIL PROTECTED]
www.IntegritySciences.com
