Date: Sun, 30 Dec 2001 00:16:33 -0500 From: Allen Landsidel <all@biosys.net> To: Rik <freebsd-security@rikrose.net>, Ryan Thompson <ryan@sasknow.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: MD5 password salt calculation Message-ID: <5.1.0.14.0.20011230000743.00a91a80@rfnj.org> In-Reply-To: <20011230043020.A9927@spoon.pkl.net> References: <20011229133456.J99302-100000@catalyst.sasknow.net> <20011229133456.J99302-100000@catalyst.sasknow.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 04:30 AM 12/30/2001 +0000, Rik wrote: >On Sat, Dec 29, 2001 at 01:49:46PM -0600, Ryan Thompson wrote: > > So, before I go hacking, hopefully someone can give me a clue to where > > I can look to calculate a new MD5 salt. > >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). > >I'm sure someone on this list will tell us if that's a completely stupid >way of generating salt... 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. Normally using some permutation of the current time is a "bad" way to do things, but in this case it's bad for all the normal prediction reasons, and two more that are pretty hefty. First, depending on the format you pass to strftime, you may be using the same salt for *hours* at a stretch. This will make prediction much easier because of the second reason I'll mention, and also because you only have a very limited number of values to use, all of them ASCII characters in the range 0-9. Brute forcing this salt would be trivially easy just because of that. 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. 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. Your best bet, outside of something like "move the mouse around randomly while I read it" is to use the urandom() function, which is initialized by the system at boot and has been designed to be as close to a cryptographically secure PRNG as possible. Using urandom() not only gives you a better (less predictable) generator to draw from, but using it also affects it's output. The more things that use urandom() the better, because the more things that draw from the pool, the less predictable it will become. 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.20011230000743.00a91a80>