Date: Mon, 27 Sep 2004 07:13:56 -0700 From: Colin Percival <cperciva@wadham.ox.ac.uk> To: Giorgos Keramidas <keramida@freebsd.org> Cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) Message-ID: <41582024.2080205@wadham.ox.ac.uk> In-Reply-To: <20040927091710.GC914@orion.daedalusnetworks.priv> References: <Pine.LNX.4.33.0111071900280.24824-100000@moroni.pp.asu.edu> <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> <20040927091710.GC914@orion.daedalusnetworks.priv>
next in thread | previous in thread | raw e-mail | index | archive | help
Giorgos Keramidas wrote: > Increasing the number of bits the hash key uses will decrease the > possibility of a collision but never eliminate it entirely, AFAICT. How small does a chance of error need to be before you're willing to ignore it? > What I pointed out was that when a non-zero possibility of two data > blocks comparing as equal (even though they are no) exists, the method > in question should not be used for password data or other sensitive bits > of information. A larger hash key will never yield a possibility of > zero, so it doesn't mean that you can sleep untroubled at night while > the rsync server overwrites /etc/*pwd.db files periodically. If an appropriately strong hash is used (eg, SHA1), then the probability of obtaining an incorrect /etc/*pwd.db with a correct hash is much smaller than the probability of a random incorrect password being accepted. Remember, passwords are stored by their MD5 hashes, so a random password has a 2^(-128) chance of working. If, on the other hand, you're concerned about accidentally locking yourself out of the server as a result of an undetected mangling of the password database... you should be more worried about the server, and all your backups, being simultaneously hit by lightning. :-) Colin Percival
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41582024.2080205>