From owner-freebsd-security@FreeBSD.ORG Mon Sep 27 14:13:58 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68CC716A4CE; Mon, 27 Sep 2004 14:13:58 +0000 (GMT) Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E27E043D3F; Mon, 27 Sep 2004 14:13:57 +0000 (GMT) (envelope-from cperciva@wadham.ox.ac.uk) Received: from pd3mr4so.prod.shaw.ca (pd3mr4so-qfe3.prod.shaw.ca [10.0.141.180]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I4P005D6E79FS70@l-daemon>; Mon, 27 Sep 2004 08:13:57 -0600 (MDT) Received: from pn2ml6so.prod.shaw.ca ([10.0.121.150]) by pd3mr4so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I4P00FZFE79MNM0@pd3mr4so.prod.shaw.ca>; Mon, 27 Sep 2004 08:13:57 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.233.42])2003)) with ESMTP id <0I4P001ZHE78W7@l-daemon>; Mon, 27 Sep 2004 08:13:57 -0600 (MDT) Date: Mon, 27 Sep 2004 07:13:56 -0700 From: Colin Percival In-reply-to: <20040927091710.GC914@orion.daedalusnetworks.priv> To: Giorgos Keramidas Message-id: <41582024.2080205@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> <20040927091710.GC914@orion.daedalusnetworks.priv> User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040922) X-Mailman-Approved-At: Tue, 28 Sep 2004 15:12:26 +0000 cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 14:13:58 -0000 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