On Wed, Feb 5, 2014 at 1:03 PM, Brion Vibber <bvib...@wikimedia.org> wrote:
> Offhand I'd say "use bcrypt", but from http://us3.php.net/password_hash -- > > "*Caution* > > Using the *PASSWORD_BCRYPT* for the *algo* parameter, will result in the > *password* parameter being truncated to a maximum length of 72 characters. > This is only a concern if are using the same salt to hash strings with this > algorithm that are over 72 bytes in length, as this will result in those > hashes being identical." > > Is the 72-byte truncation a general bcrypt problem or specific to > password_hash()? Any concerns or a non-issue? Note that some non-Latin > strings can only fit 24 chars in 72 bytes of UTF-8. Long enough for most > passwords, but some people like passphrases. :) > It's an issue with bcrypt itself (only uses 18 32 bit keys). Good point. > > -- brion > > > On Wed, Feb 5, 2014 at 12:53 PM, Chris Steipp <cste...@wikimedia.org> > wrote: > > > Hi all, I wanted to bikeshed just a little bit, to make sure there is > some > > consensus. > > > > tl;dr We're upgrading the password hash used to store passwords to make > > offline cracking more difficult. In doing that, we need to set one of the > > options as default. Speak up if you have strong feelings about one over > the > > other. > > > > > > Along with refactoring how passwords are stored and checked, > > https://gerrit.wikimedia.org/r/#/c/77645 implements two strong hashing > > algorithms PBKDF2 [1] and bcrypt [2]. I added a followup commit to add in > > the algorithm that Tim came up with in 2010 using Whirlpool as a hash > > function [3]. > > > > For any of these, there is a maintenance script to wrap current passwords > > with one of the strong ones, so we can upgrade the whole database without > > interaction from the users. It's also simple to upgrade the work factor > or > > change to a new algorithm, if we decide that is needed in the future. But > > for the actual default... > > > > Bcrypt is probably the most common option for password storage in webapps > > that I see. PHP 5.5 uses it as the default for the new password_hash() > > function. The only issue is that PHP before 5.3.7 had a flaw in their > > implementation which resulted in weak hashes. If we set bcrypt as > default, > > we would want to raise the minimum php version to 5.3.7 (it's currently > > 5.3.2) for MediaWIki 1.23. > > > > PBKDF2 is an RSA standard and is included in PHP 5.5. Tyler did an > > implementation in the patch to make it backwards compatible. The only > > downside to it is the connection to RSA, who may have knowingly > > standardized weak algorithms, although the security properties of PBKDF2 > > are fairly well studied and haven't been called into question. > > > > The Whirlpool algorithm by Tim would force password cracking software to > do > > a custom implementation for our hashes. It has very similar work effort > to > > bcrypt, and should keep our passwords as safe as using bcrypt. The theory > > behind it seems good, but obviously, we might discover a gaping hole in > it > > at some point. > > > > Is there any strong preference among these options? My personal vote is > for > > bcrypt, if bumping the php version doesn't seem like a big deal to > > everyone. > > > > > > [1] - https://en.wikipedia.org/wiki/PBKDF2 > > [2] - https://en.wikipedia.org/wiki/Bcrypt > > [3] - > > http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg08830.html > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
