Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Encryption Security IT

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?."
This discussion has been archived. No new comments can be posted.

NYU Group Says Its Scheme Makes Cracking Individual Passwords Impossible

Comments Filter:
  • by Anonymous Coward on Thursday April 03, 2014 @11:51AM (#46649931)

    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)

    by holophrastic ( 221104 ) on Thursday April 03, 2014 @11:52AM (#46649935)

    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)

    by parallel_prankster ( 1455313 ) on Thursday April 03, 2014 @12:05PM (#46650107)
    Yes, did you RTFA? They specifically mention that this step is needed everytime the system boots. They have also provided some ideas on how to achieve this automatically.
  • by Anonymous Coward on Thursday April 03, 2014 @12:25PM (#46650331)

    Sadly thats not true. When the attacker has the password database SRP degrades to being just a regular salted password.

  • by squiggleslash ( 241428 ) on Thursday April 03, 2014 @12:40PM (#46650499) Homepage Journal

    Just to make it clear, because a lot of posters here appear to be confused as to what this is for:

    This isn't about securing individual passwords. This is about securing collections of passwords and doing something about situations where some website's master table of usernames and hashed passwords gets leaked, somehow.

    Right now, when that happens, people with the password "123ABC" (or "password" or "secret" or whatever) are easily identifiable because you can look for the hashes of those texts amongst the passwords.

    However, with this technology, you would need to already know a large number of existing username/password combinations before you could begin to look for users with easily guessed passwords.

    How secure is it? Well, put it this way: if the system is rebooted, then it won't become available until a large enough body of users has tried to log in...

  • Re:WTF? (Score:5, Informative)

    by Kjella ( 173770 ) on Thursday April 03, 2014 @01:34PM (#46651105) Homepage

    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)

    by kasperd ( 592156 ) on Thursday April 03, 2014 @01:48PM (#46651247) Homepage Journal

    So... how do you know if a user can log in? You have to wait until a bunch of users want to log in simultaneously?

    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.

BLISS is ignorance.