A password hash storage scheme that prevents efficient password cracking
github.com
github.com
From the paper:
> The server will restart periodically. All data kept in memory is lost at this point and the server must restart using only the data on disk – which is attacker visible.
So I guess your solution is correct and trivial but the author's solution doesn't use data from outside, not even a user provided symmetric key.
https://github.com/PolyPasswordHasher/PolyPasswordHasher#if-...
>provide enough passwords
Why don't they just store some dummy users' (with zero privileges) credentials directly on the hard drive? They simply can provide valid passwords from it after reboot and your attacker can have these passwords since they can't do anything with them. Maybe their leak strategy involves something like this?
The alternative solutions does not mention doing what you suggest, but reboots would be problematic. Of course you could do the same thing for bootstrapping as they do (leak a portion of the salted hash to disk and use that for verification), but that I'm pretty sure that allows probabalistic cracking of weak passwords (assuming most passwords are weak, the weakest password that matches is likely to be the password).
The advantage is that the administrator doesn't need to manually intervene, the disadvantage is that you can't verify passwords (in a way that is more secure than just verifying hashes) until you get at least K correct login attempts.
If the goal is only to defend against SQL injection, a much simpler solution is to just put the key outside the database, for instance in the configuration or source of the application.
Does this suffer from the same issue?
It isn't necessarily an important issue. Maybe nobody will figure out they can take down your service that way. Maybe rate limiting is enough. Maybe you can solve it by having servers dedicated to hashing.
I was just curious about the performance characteristics:
Suppose that three people have passwords that are each randomly chosen and 6 characters long. A typical laptop can crack those passwords in about 1 hour. If you take the same passwords and protect them with PolyPasswordHasher, every computer on the planet working together cannot crack the password in 1 hour. In fact, to search the key space, it would take every computer on the planet longer than the universe is estimated to have existed.
The contradiction is that if users can log in to your service quickly, then they can try a lot of passwords quickly. So is this more expensive than scrypt?
If an attacker has read-only disk access, they can swipe any unencrypted data. Scrypt protects you from this, and it's straightforward about the requirements and computation costs.
In practice, what kind of CPU usage would a PolyPasswordHasher scheme need?
Experts have said that scrypt can be safely used with server relief (see link below). But I'm not sure whether PolyPasswordHasher can be safely used with server relief (i.e. without leaking secrets to the client). Perhaps someone more knowledgeable will pitch in with a better answer.
'Server relief' is dumb... correctly implementing a 'hashcash'-like scheme to prevent excessive CPU resource commitment is non-trivial. It will require either persistent pre-login server state, and/or cryptographic IP/session binding, both of which open up a second DoS vector.
Implementing Scrypt etc in the browser doesn't completely prevent DoS, and sacrifices your ability as an operator to ensure passwords are being appropriately salted and munged (because of third party clients, unauthorised API users etc). Plus, attackers can just start using malicious webpages or botnets to crowdsource their hashing efforts which, because it scales horizontally, could actually speed things up for an attacker if you're server isnt doing any rate-limiting on the final hash+authentication stage.
At some point you have to accept that administrators will need to do some work, and if 200 IPs are trying to log into the same account 5 times every 15 minutes you should probably email the user and lock the account.
Nobody stops an attacker to use a fixed password and cycle the username. If your site has lots of users this could work pretty well. Your site could even "leak" (like forums) usernames making this approach more efficient.
But what stops a malicious attacker from registering a bunch of dummy accounts, and then using the known passwords to reconstruct the Shamir Secret?
(I also haven't read the paper, but the concept is intriguing).
If you're going to introduce a new one, it should go through at least the same level of cryptanalytic scrutiny before anyone uses it.
Basically, a lot of people will use the same credentials on both (for example) Ashley Madison and their bank. If AM does a bad job storing their passwords, then an SQL injection there can be used to reconstruct the users' passwords and then log into many of their banks.
The root of the password problem is that people don't use a password database. I didn't until recently, even though I was aware of the risks. It was more than I could be bothered to do. Apparently Rayiner wasn't using one until recently as well. It seems pretty likely that most people won't use one unless they're forced to.
The effect of this is that if you use the same password on many services, you're at a pretty big risk. What do most users do, then? "Ah, I'm clever; I'll put the name of the service in the password."
Trouble is, this is exactly the same as the previous situation. You're sharing passwords across services, whether or not you thought so. The first thing that an attacker will do when they reverse your password is scan it for instances of the service name. If your password is "DropboxFoobar", it's likely your Twitter's is "TwitterFoobar". In fact, passwords of this type are the most valuable to an attacker, because it's a surefire flag of "You can get a ton of data from this person if they use the same scheme everywhere!" (When you reverse other types of passwords, it's unclear whether it's worth the effort to try it against a bunch of services.)
That said, anything to improve this situation is worthwhile effort. Whether it's a new hashing scheme or a public service video about the dangers of not using a password database, security improves incrementally. Shielding a modern company is extremely hard, as it requires all employees to use the same security measures. Anything that can be automated would be a win.
Are there other automatable things besides hashing? Phishing attacks can't be detected because they're crafted so well. SQL injection can be, though: Throw your server requests through a bayesian filter and watch it decide to put requests containing SELECT into their own class automatically. Defenses to social engineering are close to impossible: if someone wants to get into your building, they'll pose as a maintenance crew. If they're discovered, they'll say "Sorry, my work order must be for a different floor."
All in all, this is the general essence of why Sam Altman's desire to fund new security companies is good, but might not produce many results.
So are incorrectly stored passwords really the problem? Well... Not if you're using bcrypt or scrypt. Possibly this scheme; time will tell. The research is valuable for other reasons too: it's a whitepaper with source code, which is extremely rare. Might be good to encourage more of that.
You would need enough logins for it to calculate the true line before it could create any new passwords.
During normal operation it has a black box that validates passwords quickly. The PloyPasswordHash is the key to how it does it - but really it doesn't matter. All that matters is a password (or a hash of it) goes in, the blackbox maybe reads some data from the (effectively public) password database, and a yes/no comes out at the cost of stuff all CPU time.
The point is - if you can reproduce the blackbox once per GPU node on a password cracker it's no better than any other scheme.
So the security of the scheme rests on the attacker not being able to reproduce the blackbox. If it were a real blackbox sitting somewhere secure then maybe - but it's not. They make a large point of saying this scheme has no secret hardware sauce - is it's just software, in reality just another process running on the web server. If you managed to get a copy of the memory image of that process it's game over. But we can't use that weakness to attack it because it is acknowledged in the paper.
During normal operation the blackbox creates it's secrets by effectively combining a _lot_ of passwords (say N) from users. Thus you need N valid passwords before you can crack one. I think they achieved that, and it does indeed make the it near impossible to recreate the blackbox by brute force - if all you have is the public password data base and a copy of the code.
But it's not that simple. Firstly they acknowledge a naive implementation doesn't work because an attacker can just create N accounts and feed the passwords to the blackbox so it can initialise itself. In addition there is a bootstrap problem - no user can validate their password until N password have been gathered by having N attempted logins.
They get around that by having N (or close to N) special accounts which they call protector accounts. These accounts are presumably created by the server admin and thus can be trusted. They are used for both bootstrapping (implying they are available at boot time) and preventing the flood attack (by insisting some of the special accounts must be part of the N).
And so we get to the real issue: the passwords for those accounts must be entered when the machine boots. Effectively they are the secret the blackbox needs to do it's stuff. Replacing the PolyPasswordHash with a process that demands a single secure password be entered when the machine boots would work just as well. Eg, that password is an extra salt fed to a cryptographic hash along with the password word and on disk salt, and the result must match the hash stored on disk. Without knowing that salt there is no way to validate the passwords.
Sure entering N passwords isn't hard, but would you enter N passwords when there is a method offering equivalent security when you enter just one? And even that isn't the real issue - the real issue is fuck all corporations on the planet have employees willing to be woken up a 2 AM in the morning when a server boots to enter just one password.