https://bugzilla.wikimedia.org/show_bug.cgi?id=28419
--- Comment #50 from Daniel Friesen <mediawiki-b...@nadir-seen-fire.com> 2012-07-10 03:08:28 UTC --- (In reply to comment #46) > This: <http://www.opine.me/a-better-way-to-store-password-hashes/> sounds like > a possibly good idea. Would require schema change (one or another way) though. That's an interesting read. But I'm not really buying it. At least not for the case of MediaWiki. Firstly, I don't buy the whole "large pile of spaghetti data == slow password cracking". The task of brute forcing passwords is still the same general pattern. Take user salt, generate password, validate. Where validation is a lookup in this big pile of data instead of an equality test. I don't consider this as big of a hurdle as the author seems to think of it. Firstly, the author mentions "search the entire Hashes table". But this is a complete characterization of the job involved here. There's no need to do anything as slow as a search of the table. This is a very simple existence check. And we've already developed numerous ways to speed up that kind of test. Anyone with enough brains to get ahold of this data is going to be smart enough to use some sort of index for this. Done in a way that optimizes it's RAM usage. Not shoved into some database that does things it does not need to. The operation isn't going to take long. I'm also skeptical about "big RAM requirement". Last I checked for this kind of task an index of the data is actually smaller than the data itself. And it's not that hard to get 32GB of RAM into a machine. This means that the GOAL of this way of doing password storage is to make sure that your password storage alone takes up well over 32GB of disk storage. Even if your wiki doesn't even use 1GB of data storage. The article also suggests that the need to store the entire table of hashes would somehow be a hard feat. This might be true if you assume the only way someone is going to extract the data would be with SQL injection. But that's not the vector we're focusing on. I believe we're more worried about things like database backup leaks. And other types of vulnerabilities which in the end, the attacker likely already has access to the whole data. Though most of what I rebutted isn't even the biggest issue here: - Most MediaWiki installations run on VPS servers, shared hosts, etc... where they have disk capacity limits under 20GB of storage. - This article suggests that basic password storage should be so hard that you can't store it on a USB stick and can't fit it in ram. This practically necessitates password storage over 32GB. In other words. This doesn't seem to work for 99% of MediaWiki installations without forcing thousands of wikis to start paying hosting costs several times what they are currently paying. It also practically spits on the idea that small sites should keep backups of their data. If password storage bloats databases to this size I doubt as many small sites are going to be willing to keep backups. (In reply to comment #48) > (In reply to comment #47) > > Damn. That's one of those ideas you can't believe you never thought of > > before. > > This is simply ingenious and I plan on taking my hand at implementing it > > unless > > somebody has an objection. > > Password reset may be a problem, since you have to disable the old password > when resetting new. You may do it by changing salt, but the old one will > remain > forever, so we will probably need password change throttling or something like > that. A logged in user wants to change their password. And we're going to get in their way? Frankly this way of password storage implies the need for large data storage. So I don't believe that password change spamming is as big of an issue as the data storage itself. Frankly if the frequency at which users change their password creates an issue, then there is something fundamentally wrong with the password storage. -- 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
