Date: Thu, 28 Jan 2010 15:10:26 -0500 From: Bill Moran <wmoran@collaborativefusion.com> To: Chris Palmer <chris@noncombatant.org> Cc: freebsd-security@freebsd.org Subject: Re: PHK's MD5 might not be slow enough anymore Message-ID: <20100128151026.5738b6c1.wmoran@collaborativefusion.com> In-Reply-To: <20100128193941.GK892@noncombatant.org> References: <20100128182413.GI892@noncombatant.org> <20100128135410.7b6fe154.wmoran@collaborativefusion.com> <20100128193941.GK892@noncombatant.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In response to Chris Palmer <chris@noncombatant.org>: > Bill Moran writes: > > > I'm sure someone will correct me if I'm wrong, but you can't do this > > without establishing this as an entirely new algorithm. The hashes > > generated after your patch will not be compatible with existing password > > files, thus anyone who applies this will be unable to log in. Have you > > tried it? <snip> > Since there is 0 cost for people installing > fresh, there is no reason not to do it. Are you volunteering to handle all the complaints from all the people who want to upgrade their systems without reinstalling? This would also introduce a complete incompatibility between systems. I, for one, frequently copy password files from one system to another. I expect $1$ to be compatible on all systems. If a new algorithm is to be used, why even start with md5? Why not start with something that's inherently stronger and more CPU intensive? >From there, assign it a new algorithm number. See the "Modular Crypt" section of crypt(3). Then compatibility is maintained. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100128151026.5738b6c1.wmoran>