NYU Group Says Its Scheme Makes Cracking Individual Passwords Impossible 277
An anonymous reader writes "Researchers at New York University have devised a new scheme called PolyPassHash for storing password hash data so that passwords cannot be individually cracked by an attacker. Instead of a password hash being stored directly in the database, the information is used to encode a share in a Shamir Secret Store (technical details PDF). This means that a password cannot be validated without recovering a threshold of shares, thus an attacker must crack groups of passwords together. The solution is fast, easy to implement (with C and Python implementations available), requires no changes to clients, and makes a huge difference in practice. To put the security difference into perspective, three random 6 character passwords that are stored using standard salted secure hashes can be cracked by a laptop in an hour. With a PolyPassHash store, it would take every computer on the planet longer to crack these passwords than the universe is estimated to exist. With this new technique, HoneyWords, and hardware solutions all available, does an organization have any excuse if their password database is disclosed and user passwords are cracked?."
Re:This idea is really BS (Score:2, Informative)
This scheme fails in practice (another over-hyped idea that fails to deliver as has gotten so common these days): It requires a number n of users to log-in before any password can be checked! That is right, the first n-1 have to wait until n are there, because before n good (!) passwords are available to the server, it cannot verify even one.
You must have skipped reading TFA. The "different" logins can be administrative passwords, so that whenever a login is attempted, the user passwords is only one of multiple passwords, where the other passwords can be administrative passwords. The point is to make the password file, when stolen, be safer. If you do not have aceess to the administrative passwords, the cracking of the passwords from the stolen file gets too computationally intensive.
Running memory (Score:4, Informative)
The article says: "if an attacker can read memory on a running server, they can steal passwords unencrypted regardless of the technique that is used".
The article concludes that al we're trying to do is to resist passwords stored on-disk. Congrats. So here's my fix-all solution. When the server is booted, it loads all of the passwords into memory, and then physically disconnects the disk. And we're done. You know, except for the whole entire memory space.
This is just another one of those "make this link in the chain even stronger because once someone broke through it" forgetting that there are dozens of other weaker links that simply have yet to be targetted.
Re:WTF? (Score:5, Informative)
Re:SRP (Secure Remote Protocol) (Score:2, Informative)
Sadly thats not true. When the attacker has the password database SRP degrades to being just a regular salted password.
Comment removed (Score:4, Informative)
Re:WTF? (Score:5, Informative)
Does it come with an actual monkey? I wouldn't want to end up with an MSCE or some other poor substitute, monkeys are both cuter and put less shit on your servers. Of course both could be replaced by a very small shell script. but I need one for the head count and scripts run headless so that won't do.
Re:WTF? (Score:4, Informative)
Exactly. The first of those users will experience the password validation taking longer than usual. How much longer depends on various parameters in the system. If some of the users gave up and closed the connection, you still have the information needed for unlocking, so you don't need all of those users to log in simultaneously. You just need enough different users trying to log in after a restart. Once the threshold is reached, that user will get logged in after having to wait at most a couple of seconds. Earlier users will get logged in at the same time if they are still waiting.
But I suspect you might be able to DoS that process by just submitting a stream of invalid passwords. They may be able to avoid that through the partial validation described in the paper, but the partial validation sounds like it leaks so much information, I would rather trust an old-school salted hash.