https://bugzilla.wikimedia.org/show_bug.cgi?id=28419
--- Comment #82 from Daniel Friesen <[email protected]> --- (In reply to comment #81) > With recent events [0], I'd like to capitalize on lots of people wanting this > and get it pushed through soonish. > > I think we actually have 3 parts to the bug: > * Updating MediaWiki to better handle multiple password types, and make it > easier to extend by extensions and in the future. There were probably a > couple > of things I would change in Tyler's now-abandoned Gerrit change #77645, but > I think > it's close. Tyler, what would it take to finish that? This is done in the password branch: https://git.wikimedia.org/log/mediawiki%2Fcore.git/refs%2Fheads%2Fpassword-hashing > * Updating the current WMF database to use a stronger format. Tim's > suggestion > from 2010 I think is still pretty good (although we would probably want an 8 > or > 9 work now). Bcrypt could also be used in a similar way (take the bcypt of > the > :B:-format hash). Whatever the WMF uses, we'll probably use something that we > can do a one-way conversion from :B: hashes, so that we upgrade our entire > database without user interactions. However, php 5.3.7 is required for a > sane, > native php version of bcrypt [1], so I'm actually leaning towards Tim's > Whirlpool at this point. The password-hashing branch uses PBKDF2-HMAC+Whirlpool. Passwords are converted on login/change. > A couple times on this bug pepper was brought up, which would have saved us > in > this recent incident, since only database tables were leaked and not our > private code repo. So I think we need that included in whatever :C: method we > chose. In our case, I think adding an HMAC keyed with a secret (the "pepper") > would work. Then if our secret is ever stolen (but not our password hashes), > we > can keep adding new pepper keys, and re-store our hashes with another HMAC > applied using the new secret. This is actually what held up the password-hashing branch. I was trying to make it possible to implement layers in the system other than just hashing/key derivation types. I didn't try to get password-hashing into core (which otherwise is pretty much ready) as adding this layering would require some changes to the class API that would have needed extra backcompat work if I didn't make the changes before being released. Under that incarnation of the system the "pepper" would have to be implemented through encryption rather than salting. ((Though thinking about it now, that's actually not much of a minus. Doing it that way actually means if just your pepper leaks you can change it without user interaction.)) Though if I convinced people to make a schema change expanding the user_password size I "might" have come up a way to let the system use pepper rather than encryption for some password types. > If both the pepper and the hashes are stolen, then we need (a good) way to > force password changes, but I'll open a separate bug for that. Tell me when you have one. A system somewhere to do that sounds good. A simple flag is one possibility. Though something slightly more complex is probably desirable so that we can give proper messages like "<X> admin has flagged your account as requiring a change of password" or "Due to <information about some leak> we are requiring all users to change their password". -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
