Kurt Seifried wrote:

So a password of 6 characters using only a-z would require ~1.2 terrabytes to store it, not to bad. A password of 6 characters with a-z, A-Z, 0-9 would require ~230 terrabytes (poetic license taken for database storage/indexes/compression/etc).....

Kurt, I had difficulty trying to understand your presentation. Thanks for inspiring me to attempt to understand this stuff more thoroughly. Please take a look at my analysis of the situation. Do I have it right? Uncompressed I get storage costs 20-times greater than the figure given above. This is rather a large amount for clear-text password strings of strictly six characters? I'm surprised - consider password strings of eight characters! Am I making some fundemental errors in my analysis?

......... The moral of the story: you need to protect the password file, since an attacker can glean the salt used from it, reducing their workload considerably (by a factor of 4096)....

In fact, if the attacker is not in possession of the encrypted form of the password, the system on which the password is held MUST be used to do the password lookups. This not generally practicle.

....... You also need to make users choose strong passwords, if they choose a word you are probably up the creek, taking a dictionary with 4 million words (ie almost all words, names, etc, including foriegn languages) and you can hit a lot of passwords, tests I have seen usually 1-5% of passwords are set to the username, system default, or somehting like "password", meaning an attacker can get their foot in the door easily.

The "problem" with crypt is it is relatively "cheap" to run through combinations/etc. MD5 and Blowfish provide a much stronger one way hash and the attacker will need a lot more time to generate a lookup database or brute force them. I.e. it mush less harmful if someone steals the /etc/shadow from my OpenBSD box (which uses blowfish) as opposed to a crypt'ed password file off a SuSE box. Now I need to eat breakfast.

As you say, when the attacker is in possession of the encrypted form, a great encryption algorithm is of very little help if the password is weak. Schemes which allow the use of phrases, and which tend break the eight-character limitation of "crypt" passwords are to encouraged. Strong passwords are essential no matter which algorithm is used. Cheers - Les Catterall Given: (1) The salt is a two-character string taken from the set of 64 characters, [a-zA-Z0-9./]. => There are 4096 permutations of the salt (ie. 64^2). (2) Iff the clear-text password is strictly a six-character string taken from the set of 62 characters, [a-zA-Z0-9]. => There are 5.68E+10 permutations of the clear-text string (ie. 62^6). As Kurt points out, we could choose from a set of 94 characters, and we could require the use of strictly eight-character strings for the clear-text password. This would yield 94^8 permutations (ie. 6.1E+15 permutations) of the clear-text string. (3) From (1) and (2) there are (64^2)*(62^6) permutations of the combined salt and clear-text string: => 4096 * 5.68E+10 permutations = 2.33E+14 permutations (or 233E+12 ~230 TerraPermutations) Or using strictly eight-character clear-text password strings: => 4096 * 6.1E+15 permutations = 2.5E+19 permutations (4) Now the clear-text string and salt are input to "crypt", and these are used to produce the remaining 11 characters of the encrypted password. For our brute force lookup table involving strictly six-character clear-text passwords, we are going to need 2.33E+14 entries each of 20 characters: => salt(2)+encrypted(11)+clear-text(6)+record-seperator(1) (5) Thus the uncompressed storage requirements for our lookup table of strictly six-character passwords is: => 20 * 233E+12 characters ~ 4600 Terrabytes (assuming one character per byte - uncompressed). Anyone care to guess the 8-character password that yields the following encrypted form: tWKkoqoSYcJ0k Hint: I used "crypt" to encrypt it, and drew the password from the 94-character set [a-zA-Z0-9]+[punctuation]. That's a zero in the encrypted string not an 'Oh'.