Date: Sun, 30 Dec 2001 00:58:08 -0500 From: Allen Landsidel <all@biosys.net> To: "Jacques A. Vidrine" <n@nectar.cc>, Allen Landsidel <all@biosys.net> Cc: Rik <freebsd-security@rikrose.net>, Ryan Thompson <ryan@sasknow.com>, freebsd-security@FreeBSD.ORG Subject: Re: MD5 password salt calculation Message-ID: <5.1.0.14.0.20011230002742.00afd4b8@rfnj.org> In-Reply-To: <20011230052725.GB80312@madman.nectar.cc> References: <5.1.0.14.0.20011230000743.00a91a80@rfnj.org> <20011229133456.J99302-100000@catalyst.sasknow.net> <20011229133456.J99302-100000@catalyst.sasknow.net> <5.1.0.14.0.20011230000743.00a91a80@rfnj.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:27 PM 12/29/2001 -0600, Jacques A. Vidrine wrote: >On Sun, Dec 30, 2001 at 12:16:33AM -0500, Allen Landsidel wrote: > > At 04:30 AM 12/30/2001 +0000, Rik wrote: > > >Salt is just some randomness thrown in so that you can't just make a > > >standard dictionary to compare hashed passwords with. All you need to do > > >is make the relevant number of random chars. Personally, I just run the > > >current time as a string (from strftime(3)) through the hash, and take > > >the first couple of chars as an index into an array of allowable chars > > >(modulo the size of the array, obviously). > > > > That's a completely stupid way of generating a salt. ;) > > > > Actually, it's probably about as bad as you can get without abandoning the > > salt completely. > >You are confusing salt with something that needs to be truly random. >Password salts do not, and in fact in many systems the salt is a >well-known transformation of the account name (e.g. see Kerberos). That is true.. I saw "random" and "strftime" in the same region and my eyes kind of glazed over. >[snip] > > Brute forcing this salt would be trivially easy just because of > > that. > >You don't ``brute force'' salt. You have the salt. It is part of the >crypted password. Duh. I knew that. *smacks self* > > Second, If you plan to use this in any sort of daemon, system utility, or > > something that is otherwise logged, then there is no need to guess the > salt > > at all : The current date/time will be at worst in the log file for the > > program, and at best in the last-accessed time for whatever the output > file > > is. > >There's no need to guess at all, because you already have it if you >have the crypted password [1]. > > > At this point you're probably thinking "ok wiseguy, what's a good way to > > generate the salt" and that goes to the very root of the problem; There > > really are no "good" ways (outside of some sort of biometric) to generate > > random numbers in a deterministic, finite-state machine like a PC. > >No, almost any method will do for salt, as long as the salt is mostly >different for every username/password combination. The purpose of the >salt is to prevent an attacker from precomputing the ciphertext >version of a dictionary, and then just comparing the ciphertext for >each word with the crypted password. > >For more information, see Schneier, ``Applied Cryptography 2nd >Edition'', pp 52-53 or similar. The purpose of the salt (as is stated in Schneier's book) is to make it infeasible to generate a large lookup database, so the brute-force computations have to be generated every time. Using something like strftime(3) defeats this, depending on the format used in the call. If you have 256 possible salts, then an attacker may be dissuaded from generating the lookup. If you only have 24 (say strftime was called to generate a normal human-readable time, and the two characters for the hour were used) then the purpose behind the salt is entirely defeated, and may as well be left off just to make the code cleaner. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.0.14.0.20011230002742.00afd4b8>