https://bugzilla.wikimedia.org/show_bug.cgi?id=28419
--- Comment #85 from Daniel Friesen <[email protected]> --- (In reply to comment #83) > > 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. Since the password system already easily handles multiple password formats I suppose we could come up with two password formats. PBKDF for new passwords and a :C: format that is based on existing :A:/:B: hashes that we can convert without user interaction. That said. Thinking about how the idea of :C: works it might be possible to instead create a layer that could essentially do a :C: for any non-opaque password storage type using the implementation of any other non-opaque password storage type. The fundamental idea is simply using the hash of a password as the input to a new type of password storage instead of a password. I'd need an interface for hash/dkey based password storage to expose the hash separately from the parameters. But by the layer could opaquely store the type and params used by say PBKDF, the type and params used by :B:, and the hash. With that information it would be possible to create both an instance of the B type and the PBKDF type and have the wrapper layer use the abstract methods on both classes to implement hash a password with both. That actually has the advantage over a simple :C: type of being able to wrap any non-opaque type and in the future will still be capable of doing that for any new non-opaque password type. eg: Say in the future we discover that the PBKDF algorithm is still fine but there's a weakness in WHIRLPOOL and we need to use some brand new hash type but we can't convert from WHIRLPOOL to that hash type. The same wrapper can be used to take the existing PBKDF WHIRLPOOL and then wrap it in PBKDF with the new hash type. Of course there is a small disadvantage. With a simple restricted :C: type; In the future if you created a :D:, :E:, and then :F: each time wrapping the old password hash you could keep relatively the same params. But for a wrapper layer each time you'd have to wrap the wrapper with the type and params for the new type: ((abstractly speaking `WRAP { PBKDF:params, :B:... }` becomes `WRAP { NewType:params WRAP { PBKDF:params, :B:... }` and continues like that)) While that's fine the downside there of course is that each time you update passwords en-masse and a user never logs in resetting it back to a normal password type the storage data grows in size. Eventually the size becomes large enough it won't fit in our user_password field and you can no longer convert a user's password to a new type without their interaction. > 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). I don't like the idea of recurring "expiry" per-se but that does look fine for marking users as requiring a change of 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
