https://bugzilla.wikimedia.org/show_bug.cgi?id=28419
--- Comment #25 from Daniel Friesen <mediawiki-b...@nadir-seen-fire.com> 2012-03-25 04:24:15 UTC --- Patch needs updates to use MWCryptRand for it's salt instead of the deprecated insecure wfGenerateToken I agree with the notion of storing something in the db related to the secret token. We should really be able to say "Incorrect password secret found in system configuration. You may have to reset your password by email to log in to your account." instead of saying "Invalid password or username." even when the password is right. My thought is to include say the first say 3 bytes (6 hex chars) of a sha1 of the secret key along with the other salt. This way the secret is tied to the password it was used to hash instead of to the whole database. That way we can make our password secret configuration variable an array. Because we have a sub-hash of the secret used we can hash our secrets and compare their sub-hashes with that one. If none match we have bad config and can't handle the password. If one matches then we know what secret to use. This will allow for proper migration. For example if a wiki does manage to leak it's secret along with it's database after resetting the user_token column they can change their password secret configuration. Instead of replacing the key, they add a new one to the array. Doing so means that MediaWiki is capable of validating passwords using both the new and old secret. As users log in MediaWiki would automatically re-hash the passwords with the new secret. This would allow the wiki after compromise to re-secure the passwords in the database by telling all of it's users to log back in and change their passwords. Instead of making every single password in the database completely invalid and forcing users to do email resets and call in to support just to re-secure their account. Also, I think the number of iterations used should be included in the stored string. If you upgrade your 10000 iterations to 50000 rounds all the passwords become invalid. Storing the number of iterations used means that a wiki can happily upgrade the number of iterations use without invaliding passwords and allowing them to be upgraded. Otherwise a wiki is forced to delay and potentially never upgrade to better security because doing so would break user logins. It also prevents the same issue of telling every user their password is invalid when it's not. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- 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
