Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc,comp.security.unix Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!news.idt.net!enews.sgi.com!decwrl!nntpfeed.doc.ic.ac.uk!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!hgmp.mrc.ac.uk!ebi.ac.uk!mdw From: mdw@sol4.ebi.ac.uk (Mark Wooding) Subject: Re: how MD5 works Sender: news@ebi.ac.uk (usenet news) Message-ID: <slrn5lp7hl.322.mdw@sol4.ebi.ac.uk> Date: Tue, 22 Apr 1997 11:17:17 GMT Reply-To: mdw@ebi.ac.uk References: <01bc4ecf$0b2c9840$2fa56bc7@jasmin> Organization: European Bioinformatics Institute X-Newsreader: slrn (0.9.1.1 BETA UNIX) Lines: 45 Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:39519 comp.security.unix:33856 Jian L. Zhen <jlz@isli.com> wrote: > I read thru some material for MD5 and it seems that MD5, as a one-way hash > function, will generate the same results with the same input > everytime. Yes. That's rather the point. Because you can't reverse MD5 (well, so we believe at the moment, but we used to believe that MD5 was collision resistant too...) the only way you can check whether someone's given you the right password is to hash it and compare that with the hash you've already got. If the result of a hash function changes all the time, then you've got what we call a `random number generator' which is useful, but for completely different reasons. > am I correct? is there anything in algorithm that might make the result > variable each time? (I'm not familiar with FreeBSD, or its use of MD5, if any. Actually, a quick tour of the FreeBSD manual pages available online suggest that it uses a slightly improved version of the traditional DES-based password hash, but that doesn't actually alter the main thrust of my comments below.) There's nothing in MD5 itself which gives you different answers for the same inputs. If you just use the hash of the password, then a dictionary attack becomes fairly simple: just build a database of common (and less common passwords) indexed by MD5 hash, and look up the hash in the password file to find the password. The solution is (if I'm right) to hash both the password and a short random string (called a `salt') and store both the hash and the salt in the password file. If the salt is long enough, the simple dictionary attack becomes infeasable. There's still the more tedious go-through-the-dictionary-hashing-every- entry-with-the-salt-until-you-get-a-match attack, though. I'd tend to hash the concatenation of the salt, the password, and then a megabyte or so's worth of known text (just zero bytes will do) to slow the hashing process down. (There are six possible orders for the three things, and four of them are weaker than this one; the other is password, salt, padding, which doesn't seem particularly different. I feel happier with the salt first.) -- [mdw] `How can you be so mean to someone so meaningless?' -- Selina Kyle