Hi everybody,
I was on the brink of celebrating the one-year anniversary of a patch I submitted being open, but today it was finally merged!
https://gerrit.wikimedia.org/r/77645
The old User::comparePasswords() and User::crypt() functions have been replaced with a new password hashing API. This means MediaWiki now natively supports Bcrypt and PBKDF2 as replacement password hashing algorithms. Furthermore, the system allows seamless transitioning, meaning users’ password hashes will be updated automatically the next time they log in.
This means that MD5 is almost out the door, which is a big win (a follow up patch, https://gerrit.wikimedia.org/r/149658, changes the default to PBKDF2, which would mean any wiki that upgrades to 1.24 would automatically switch away from MD5).
I’d like to thank Aaron Schulz, Chris Steipp, Krinkle, and many others who helped get this through.
-- Tyler Romeo 0x405D34A7C86B42DF
Thank you. Out of curiosity, why bcrypt and not scrypt? There is debate in the security community about which is better so my comment isn't intended as criticism. I'm just interested in the thinking behind this decision.
Thanks, Pine On Jul 28, 2014 1:35 PM, "Tyler Romeo" tylerromeo@gmail.com wrote:
Hi everybody,
I was on the brink of celebrating the one-year anniversary of a patch I submitted being open, but today it was finally merged!
https://gerrit.wikimedia.org/r/77645
The old User::comparePasswords() and User::crypt() functions have been replaced with a new password hashing API. This means MediaWiki now natively supports Bcrypt and PBKDF2 as replacement password hashing algorithms. Furthermore, the system allows seamless transitioning, meaning users’ password hashes will be updated automatically the next time they log in.
This means that MD5 is almost out the door, which is a big win (a follow up patch, https://gerrit.wikimedia.org/r/149658, changes the default to PBKDF2, which would mean any wiki that upgrades to 1.24 would automatically switch away from MD5).
I’d like to thank Aaron Schulz, Chris Steipp, Krinkle, and many others who helped get this through.
-- Tyler Romeo 0x405D34A7C86B42DF _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jul 28, 2014 at 5:24 PM, Pine W wiki.pine@gmail.com wrote:
Thank you. Out of curiosity, why bcrypt and not scrypt? There is debate in the security community about which is better so my comment isn't intended as criticism. I'm just interested in the thinking behind this decision.
It is a matter of stability in PHP. Bcrypt has built-in support in PHP, as does PBKDF2, whereas scrypt requires an extension. It should be noted, however, that the patch that was merged implements an extensible password API, so it would be trivial to implement scrypt support if we wanted to.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
----- Original Message -----
From: "Tyler Romeo" tylerromeo@gmail.com
It is a matter of stability in PHP. Bcrypt has built-in support in PHP, as does PBKDF2, whereas scrypt requires an extension. It should be noted, however, that the patch that was merged implements an extensible password API, so it would be trivial to implement scrypt support if we wanted to.
Yup: "figure out what general case your particular problem is a special case of, and then implement the general case".
Cheers, -- jra
wikitech-l@lists.wikimedia.org