Wendelmaques

Warning: this is a mail about security, not about Qt, so skip it if you are
not interested.

On Friday 24 February 2006 16:27, ing. Federico Fuga wrote:
> On Fri, 24 Feb 2006 08:25:47 -0600
> Andrew Vick  wrote:
> > Perhaps if you MD5 sum the password, that would be sufficient.
>
> If you add a "salt" to the password, yes.

You need lots of salt to make MD5 not taste stale...  

To be more precise: simple MD5 is in the realm of crackability (complexity
far below 2^64), salted MD5 is deemed secure (for low-security
applications) if used correctly (it rarely is). 

In short: I would not use MD5 in any new application (except for backwards
compatibility with older applications). There are plenty of better
algorithms out there.

First off: Passwords usually protect data or functionality. In the eyes of
an attacker the cost of cracking any protection must be higher than the
value to be gained by doing so - or the protection is bound to be broken.
Eg. if you want to protect you computer magazines from being ripped apart
by your five-year-old it is usually enough to put them in the top shelf and
give him/her plenty other coloured pieces of paper. If you want to protect
the money of Fort Knox, you better make damn sure the best equipped bank
robbers don't get through the walls or doors before a whole squadron of
security people gets down on them.

So here a few examples how you could store passwords:

1) Store them in plain text in a file that only the server can read: this
protects against "normal" users and clever users/admins using someone elses
account accidentally. It does not protect against malicious clever users
and admins.

2) Store MD5-hashes of the passwords: this will protect against casual users
and casual admins, but not against clever users and admins who know how to
use an MD5-cracker.

3) Store SHA256-hashes(*): this will also protect against brute-force
crackers. It does not protect against dictionary attacks and dumb users
using weak passwords.

(*)Note that I did not put SHA1 there, since it is already on the same route
that MD5 started a few years ago. SHA256 gives you some more margin of
protection.

4) 3 plus salting: protects a bit better against dictionary attacks - the
attacker needs longer to crack the passwords, but usually the attacker
comes from the inside anyway and has plenty of time - he/she can start the
cracker friday evening and get the results monday morning. Salting is a
good idea for another reason: it hides users who accidentally use the same
password. This can be important information for an attacker - eg. if
someone low in the "food-chain" uses the same password as the big boss, an
attacker will focus on coercing or tricking the password out of the lower
person and then use it with the boss' account. Weak salts (16bit
pseudorandom) are usually enough for this.

4b) IF you want to use MD5 you better use cryptographically secure salts: at
least 128 bits wide, unpredictable. Unfortunately you need another
component for this: a cryptographic (pseudo) random number generator. These
CPRNGs are very difficult to program if you don't have enough routine in
cryprography (I screwed up royally with my first one: it made my otherwise
good protocol crackable within few milliseconds). Some crypto-libraries
provide one, but you have to make sure you understood the chapter about
seeding them in the user manual.

5) 2/3/4 plus cracklib: run some basic checks on any new password before you
accept it for storage - make sure it contains at least one character from
each category: digits, lower case letters, upper case letters. If you have
the same keyboards on all computers: use special characters ($#@!...) too.
Make sure none of the parts of the password can be found in a dictionary
(there are plenty of test-dictionaries out there, eg. the ones used by the
Unix tools spell or dict). Enforce the passwords to be a certain minimal
length (usually: 8 chars). DON'T force the users to use system supplied
passwords! They will note them on a sticky note and put them behind
monitors or below keyboards. This protects quite well against password
crack programs - the programs will need several days or a few weeks to
crack the passwords.

6) 5 plus public-key-certificates: this is for high-security protection.
Give every user a certificate AND a password. Depending on your environment
and the stuff you want to protect the certificate may be installed
(passphrase-protected of course!) on the local machine or on a mobile token
(usb-stick, smart-card, etc.pp.). The costs both on the implementation and
the user-convenience are high for this and they better be worth it: such
measures are usually only used for financial transactions of a bank or
highly sensitive data in top secret organisations. If you plan to create a
system in that domain - you better ignore all my babbling and get yourself
a real cryptographer(*) - you'll need him!

(*)And I don't mean the sales guy from Novell or Microsoft, I mean an expert
who has a name in the cryptographic community.

A final note on communication: if you protect network traffic with that
password (eg. a client on a desktop talking to a server in the server room)
you should make sure that ALL components that are supposed to be protected
do NOT compromise what you achieved with the password protection: 

1) The equivalent is unencrypted communication. You don't care anyway.

2/3) Use at least a hashed exchange (server sends challenge, client hashes
password plus challenge, server doesn't accept if the value does not match
the challenge; the challenge must be cryptographic random). Or:

4) Use SSL/TLS for communication. (There are enough libraries which offer
this, but you might want to read a book on them before you start!)

5) Use TLS and make sure your cryptographer triple-checks its
implementation.

And a final note on logic: no amount of cryptography will protect you from
someone with super-user rights to your database/server. So you better make
sure your admins are well-paid enough to NOT have an interest in selling
your data.

	Konrad

Original: qt-interest