https://bugzilla.wikimedia.org/show_bug.cgi?id=28419
--- Comment #83 from Chris Steipp <[email protected]> --- (In reply to comment #82) > This is done in the password branch: > https://git.wikimedia.org/log/mediawiki%2Fcore.git/refs%2Fheads%2Fpassword- > hashing Thanks! I will take a close look at it next week. > The password-hashing branch uses PBKDF2-HMAC+Whirlpool. Passwords are > converted > on login/change. The issue with that is a large number of the 40M users in the WMF databases will never login again, but I'd like to make sure they have a strongly hashed password so an attacker can't take over their unused account. So I'd like to find a way we can take what's in the db, and upgrade it without user interaction. > > > 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. Encrypting the hash would work too. The ability to change it without user interaction I think is critical, but either way is fine. > > 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". Bug 54997 is what's I'm thinking right now (since I've worked with a bunch of enterprise software in the past that did it that way). -- 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
