https://bugzilla.wikimedia.org/show_bug.cgi?id=54948
--- Comment #4 from Daniel Friesen <mediawiki-b...@nadir-seen-fire.com> ---
(In reply to comment #3)
> (In reply to comment #2)
> > The simple idea was to just try both. If it's an ancient hash try it both
> > with
> > and without salt. If either matches then it's ok and you continue. ((Which
> > in
> > the case of adding this on top of bug 28419 "continue" would mean converting
> > that to fresh PBKDF based password storage))
>
> Of course, a minor problem with "try both" is that if a (user_name, user_id,
> old-style unsalted user_password) combo were to leak, it would be possible to
> log in with it directly, without even having to look it up in a (rainbow)
> table.
Hmmm, yeah you're right about that.
> Perhaps rehashing during the upgrade process could deal with that, provided
> that the original hash has not already leaked. Such rehashed passwords could
> get a special flag so it would not be necessary to apply the hack to :A: and
> :B: hashes. (Unless, of course, a wiki with $wgPasswordSalt = false upgrades
> to
> 1.13 or 1.14 first, only discovering bug 18846 too late...)
Sounds like a nice idea. Actually if we did that we could eliminate all the
back-compat code we have in User to deal with old password hashes and do
everything in the new Password system. (It's there because the old passwords
are salted with user id and the new password system is isolated so it has
nothing to do with user ids.)
To implement your idea all we'd have to do is implement an :old: password type
in the format ":old:{user_id}:{newhash}". The updater would find all rows with
old hash-only password storage. Then hash the hash and insert it with that
format into the database including the user id. Then since the user_id is now
embedded into the storage data the password system no longer needs the state of
what User the password belongs to in order to handle the password.
;) we get to kill two pieces of legacy compat with one change.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
