Forgot your password?
typodupeerror
Encryption Security IT

NYU Group Says Its Scheme Makes Cracking Individual Passwords Impossible 277

Posted by timothy
from the impossible-is-difficult dept.
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:
  • Hmm (Score:5, Funny)

    by war4peace (1628283) on Thursday April 03, 2014 @11:32AM (#46649711)

    Maybe I should look at this implementation for my upcoming MMO, which will likely go live somewhere in 2030 :)

  • WTF? (Score:4, Insightful)

    by JMZero (449047) on Thursday April 03, 2014 @11:36AM (#46649751) Homepage

    To be useful, the system still needs to be able to tell whether a single user password is correct (and needs to do so reasonably efficiently). So if someone has a 6 character password (which is dumb) you can just try all possible passwords (there isn't that many possible 6 realistic character passwords). Either lots of them work (which would a problem) or you found the password. And it didn't take all the computers in the universe forever to do so.

    Maybe this is a great system, but the hyperbole in the summary is ridiculous.

    • Re: (Score:3, Insightful)

      by pastafazou (648001)
      Posit: An infinite number of monkeys on an infinite number of keyboards will eventually crack all your passwords.
      • Re:WTF? (Score:5, Insightful)

        by CastIronStove (2602755) on Thursday April 03, 2014 @11:42AM (#46649797)

        Instantly, since all possible combinations will occur simultaneously.

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

          by g0bshiTe (596213) on Thursday April 03, 2014 @11:52AM (#46649937)
          I call it, "Monkey Improbability Hacking".

          I'll lease it to you for the low low price of .0000024 btc
      • they already have...an infinite numbers of times.

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

      by Geoffrey.landis (926948) on Thursday April 03, 2014 @11:45AM (#46649829) Homepage

      To be useful, the system still needs to be able to tell whether a single user password is correct (and needs to do so reasonably efficiently). So if someone has a 6 character password (which is dumb) you can just try all possible passwords (there isn't that many possible 6 realistic character passwords). Either lots of them work (which would a problem) or you found the password.

      No, as I understand it from the article, you can't tell if a single user password is correct, because you don't have a measure for "correct"-- all that you check whether that password points to the same place (in a multidimensional phase space) that other passwords project to. (It does seems to only work is you can assuming that all, or at least "most," of the other passwords people enter are correct).

      • by Rhaban (987410)

        To be useful, the system still needs to be able to tell whether a single user password is correct (and needs to do so reasonably efficiently). So if someone has a 6 character password (which is dumb) you can just try all possible passwords (there isn't that many possible 6 realistic character passwords). Either lots of them work (which would a problem) or you found the password.

        No, as I understand it from the article, you can't tell if a single user password is correct, because you don't have a measure for "correct"-- all that you check whether that password points to the same place (in a multidimensional phase space) that other passwords project to. (It does seems to only work is you can assuming that all, or at least "most," of the other passwords people enter are correct).

        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?

        • 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.
        • 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.

    • Clarification (Score:5, Interesting)

      by JMZero (449047) on Thursday April 03, 2014 @11:49AM (#46649893) Homepage

      So it turns out their system, after a reboot, can't just validate a single user (I guess that was a crazy assumption on my part) - it has to have logins from a number of users before it can authenticate anyone. And if you don't want the system breakable by someone just creating a bunch of accounts (eg. normal users on a public website), these prime logins have to be more "special accounts".

      Practically, if you need some special logins after every reboot in order for the system to come online, you're going to have to have multiple people assigned this job. Or one person with N passwords he logs in with. In which case, why not just give that guy a one time pad sort of thing that he primes each server with? I mean, these passwords are going to be unrecoverable and encrypted with, effectively, an unchanging key. So... uh, we have ways to do that.

      Oh wait, there's an extension that gets around this, and has the property of "the server can check and eliminate most wrong passwords right after reboot". I'm sure a lot of bosses will like that - it'll reject most wrong passwords. Great.

      It's a clever idea, but I think there's some real hard sell problems there.

      • Fine, I'll just go buy N wrenches.

      • Re:Clarification (Score:4, Insightful)

        by MarcoAtWork (28889) on Thursday April 03, 2014 @12:03PM (#46650081)

        why would you need multiple people assigned to this job? seems to me if you are really concerned you could 'prime' this system by using an attached HSM with however many random accounts/passwords you'd like to be logged in at bootup: outside of somebody physically breaking into your server room and stealing your keycard it would seem quite secure to me...

        • by JMZero (449047)

          Yeah - but that system would have nothing to do with this. If you want to do that, it's cool and it'll work.

          The interesting part of THIS system is that it can recover the secret it needs just by having multiple users authenticate. Which is a really cool property for some possible purpose, but I don't see how it fits well with the requirements of a "normal" authentication system and how that needs to respond.

          • Rediculous (Score:4, Interesting)

            by ThatAblaze (1723456) on Thursday April 03, 2014 @02:41PM (#46651797)

            So this system would work for a web-server where a bunch of people are logging in all the time. It passes test #1: It can be implemented.

            However, the security that this system imparts would only help for the first few (N - 1, depending on how many blocks are required to overlap) passwords. Once you have those first few passwords this system provides zero benefit, since you can use the passwords you know as keys to crack any future ones. If users can make user accounts then all you need to do is make N - 1 user accounts and you have completely defeated this system.

            So this system creates a HUGE new constraint on your user management system: No accounts can ever be issued to any parties outside of your home trusted zone. I suppose there might be one situation in which this solution might be useful: classified government work. In all other situations this solution is worthless.

      • by VortexCortex (1117377) <VortexCortexNO@S ... t-retrograde.com> on Thursday April 03, 2014 @12:45PM (#46650553)

        I fucking love this!

        I hope every web company uses it. That way when users realize their boycotts have the potential power of cascading effects they'll finally have to bow to our demands and implement a better password system!

      • by Kjella (173770)

        This. If you need "special" accounts just have it supply an AES key to decrypt the password database with, if you can crack that without having the key we're all in deep shit. Pseudo:

        If (databaseLocked)
        TryDecrypt(database,password)
        If (ok)
        Print "Alright, have fun"
        Else
        Print "Sorry, service down"
        EndIf
        Else
        LoginUser(username, password)
        EndIf

        I guess you could do

      • by kasperd (592156)

        Or one person with N passwords he logs in with. In which case, why not just give that guy a one time pad sort of thing that he primes each server with?

        Actually for that we can just use a single strong password which could for example have 128 bits of entropy. So you just need to have one employee capable of memorizing a strong password, probably it would be a good idea to have a few such employees for redundancy.

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

      by Chris Mattern (191822) on Thursday April 03, 2014 @11:56AM (#46649993)

      So if someone has a 6 character password (which is dumb) you can just try all possible passwords (there isn't that many possible 6 realistic character passwords).

      No, it doesn't work that way; that's the whole point. If you have the hash and are trying to compare against it, you can't just try all the possible passwords because if haven't cracked the other passwords you don't know how to produce the hash that corresponds to a given password. If you're just trying passwords at a login prompt, brute force is trivial to defeat (best method will most likely be simply imposing an increasing login delay with each wrong attempt).

      • by JMZero (449047)

        Yeah - I was wrong. I had assumed that the system would need to be able to log in a single user based on their password (crazy me!) and that was incorrect.

      • by khasim (1285)

        More like you have the hashes for all the passwords (you downloaded it when you cracked their server).

        And you have ONE password that you created on their system. So you have a password and a hash for that password. From which you can probably deduce the "salt" used.

        But you cannot get the passwords from the other hashes because they each use a different "salt".

        The problem is that the "salt" for each password is calculated by that machine based upon "special" accounts providing correct passwords that provide

        • There's no requirement for "special" accounts, though that could be used.

          The other option is to just allow your regular users logging in after a reboot to hit the threshold. This would be good for a busy site, where 1,000 users try to log in sooner than an admin can be alerted. That brings up the question of how you authenticate those first N users. The solution is the paper allows a weak authentication before the threshold is hit, so the server could allow "slightly wrong" passwords for the first 30-60 s

          • by khasim (1285)

            The solution is the paper allows a weak authentication before the threshold is hit, so the server could allow "slightly wrong" passwords for the first 30-60 seconds after it starts up.

            Yeah, I think that's a problem. There shouldn't be any way to tell a "slightly wrong" password from any other wrong password.

            That brings up the question of how you authenticate those first N users.

            Which is a different problem with that approach.

            They could have also had the server admin type in the formula for the line that the

    • by Sqr(twg) (2126054)

      The point here is that you cannot test a single password. You must test, say three, at a time. (So you'd have to try all combinations of 18 characters in this case.)

      The downside of the method is that after a server reboot you will have to wait for three trusted people to log in before you can authenticate any of them (unless you also have a weaker system to use for the first few logins.)

      • by Jack9 (11421)

        > The downside of the method is that after a server reboot you will have to wait for three trusted people to log in before you can authenticate any of them

        Or automate 3+X system-known accounts that the system randomly logs into, as part of the bootup process?

    • by donaldm (919619)
      Actually if a cracker wanted to get a user's password all they need to do is contact the target in a so called official manner stating that they think that their account has been compromised and they need their password to check. Surprisingly many people would actually fall for this so a cracker would prefer to use social engineering to get a password rather than try the brute force method which would normally raise alarm bells with System Administrators. Of course this assumes that the System Administrator
    • by Bengie (1121981)

      and needs to do so reasonably efficiently

      If you're using bcrypt or some other stretcher, the last thing you're thinking about is efficiency. The whole point of a stretcher is to be inefficient.

  • 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. Unfortunately, n is also the security gain. That means if you require 10 different login-attempts before you can login anybody, you just get a factor of 10 in addition

    • Re: (Score:2, Informative)

      by Anonymous Coward

      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.

      • by tepples (727027)
        Good luck contacting the administrators every time you have to reboot any of the servers, especially if it's night in their time zone.
      • by gweihir (88907)

        That completely breaks security, as these passwords have to come from some place and are vulnerable there. Or it means that a large number of people (remember that it requires n users for a security-factor of n?) have to log-in (or rather attempt to) manually.

        Sorry, but you do not understand the security and attacker models at work here at all. Sure, this thing looks like a good idea, but only as long as you ignore reality. And BTW, whenever has a server password-list stolen from a not-running server or at

    • Plus, for most websites, you can just register 10 accounts, giving you the 10 known passwords.

      In any case, the treat model is that you can access all the data in the db, but not all the data in memory (as
      is the case with SQL injection and most other attacks). The
      memory is used to cache the first n-1 passwords. The n-th guy needs to wait only after the system crashes
      and the cache data is lost.

      But in such a treat model, the problem can be solved in a way simpler fashion: just store in memory a key
      with which a

      • by gweihir (88907)

        Indeed!

        As for root on the machine: Password hashes (properly stretched and salted) protect only the users that do not log-in while the machine is rooted, but these they do protect well. As password-stealing for large password files usually gets noticed pretty soon and often before the password file is completely stolen, this does offer some level of protection.

      • Register 10 accounts, or use the most common passwords on various combinatons of account data for about 5 minutes.
        • The latter is not feasible, because you don't need to guess passwords, you need to guess user-password pairs.

    • by Copid (137416)

      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.

      It would be interesting to know what the dynamics are of password database size vs login frequency. A lot of systems get huge numbers of login requests in very short timeframes, so it may not be a problem for them. But the flip side is that user bases that huge often have large

    • >> Sane people will stay with salting and stretching, ideally with scrypt() to neutralize GPUs.

      "Key stretching is orthogonal to PolyPassHash and could be trivially used in conjunction."

      Hell, just the bit about bcrypt, etc. using a unique hash per password would have stopped most of these "grab the file then crack the table" hacks; the current focus of developers should probably just be to replace anything still using unsalted (or common salt) MD5/SHA1/SHA256 schemes.

      • by gweihir (88907)

        Salts do not help that much today, as brute-forcing is faster than generating rainbow-tables. The stretching (i.e. hash iteration) is what brings the real gain. Sadly, even people that develop security software in the financial sector often do not seem to know that.

        • by mlts (1038732)

          What really needs to happen is separation of duties and storing the hashes the same way companies store private keys used for signing... a physically secure, hardened appliance with a limited interface out. Backups are done to a USB port physically on the appliance, and the data never is exposed on the network, only calls to use it.

          We can use bcrypt, initial hashes, and such, but it might be better to consider a different protection method -- keep the data separate and physically isolated from everything e

        • by kasperd (592156)

          Salts do not help that much today, as brute-forcing is faster than generating rainbow-tables.

          Salting provides lots of security against brute force attacks. Let's assume you have a system with one million users and you have a list of the 10 million most common passwords. If the system uses unsalted hashes, you only have to hash those 10 million passwords once to know which users have been using a password from that list. If OTOH the hashes are salted, you have one million salts and 10 million passwords. That

          • by gweihir (88907)

            Salting actually provides no security at all against brute-forcing. Salting helps against rainbow-tables, but that is a different attack.

    • by RKThoadan (89437)

      While I'm not necessarily all that impressed by this, your specific criticism doesn't seem to be valid. It appears that n accounts are pre-created with null information and assigned out as needed. When those are about to get used up another n are created. There would appear to be a possible attack on a new account by creating lots of dummy accounts to have a big chunk of the password space under your control, but that seems like a pretty uncommon circumstance.

      What I like about it is that it seems to protect

      • by gweihir (88907)

        It is a "threshold-scheme" any n passwords out of the whole set of passwords will do.

  • Any Excuse? Yes. (Score:5, Insightful)

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

    Security isn't about safety. The vast majority of passwords are for identification, rather than security. And the ones that are for security, are for a "reasonable" amount of security. The biggest point is to make breaking it an obviously-intentional exercise -- because that can be made illegal. It's not about stopping criminals. It's about defining criminals.

    So go ahead and make your twitter account password super-secure so that no one can ever hack in. And then go home to your cylinder lock, easily pickable, next to the big glass window. Then tell us how safe you are -- remembering that whether or not you keep your twitter password on a sticky note, and whether or not your desktop e-mail is accessible within your home without a password, your children and your wife, and your dog are sleeping behind not such password.

    And any locksmith can break into any car, as a ten-second paid-for emergency service. And so can anyone who's watched them do it.

    Stop trying to feel safe. Just feel safe. It's a lot easier, cheaper, and much more valid.

    Did you leave your oven on?

    • No? Maybe? (Score:5, Funny)

      by OglinTatas (710589) on Thursday April 03, 2014 @12:52PM (#46650635)

      Did you leave your oven on?

      You bastard. Did you have to do that?

    • Your argument is dumb.

      Security is about accessibility, integrity, and confidentiality. Passwords are used to authenticate, while access control schemes are used to authorize. Authentication and authorization come together to tell you if a person is allowed to read or modify data and permissions on data. Other security systems (High-availability, etc.) help ensure accessibility--integrity as well, since destroying data makes it non-accessible.

      Security is a risk management scheme. If the severity of

  • by H3lldr0p (40304) on Thursday April 03, 2014 @11:43AM (#46649809) Homepage

    The problem is a human one, however.

    Yes, this makes it harder should someone get to your stored hashes. But it doesn't make it any more secure if people continue to use "123ABC" as a password. Which they will do since that's an easy thing to remember.

    • Yes, it does make it more secure. The security of the hash files relies on a secret stored in memory. To
      get that secret, you either need to know the password of K users (user i has password p_i) or you need
      access to memory. The point is that access to disk is not sufficient (regardless of how weak the passwords
      of the users are).

    • 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...

      • Make passwords 20 characters. Lower case letters and the underscore or space. Expire once per 100 years. More than 60 attempts in 60 seconds gets a 60 second ban. Tell the user to slap 4 random dictionary words together. Use a random salt value per-password and a strong hash.

        QED.

  • 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.

    • by Jeremi (14640)

      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 targeted.

      If you can think of a way to strengthen all of the links simultaneously, by all means post it and/or start a company and get rich selling your perfect-security technique.

      If, on the other hand, you can't, then strengthening the links one at a time may be the best we can do. Unless you think it's better to leave them unnecessarily weak?

      • Think harder boy. I believe in removing links, having fewer links to strengthen. It's called reducing the surface area of attack -- at least it was in the 80's, when I did start my own successful company.

        You may be forgetting, if you've ever actually known, that chains are used because they are inexpensive to produce. They aren't better than cables, and they aren't better than lines, and they aren't better than rope -- when better equals stronger. But they are more flexible than cable, way faster to pr

  • Given enough opportunities to try different combinations, any password can be guessed in a finite amount of time, eventually.

    Or maybe they just mean impossible for all practical purposes...?

  • PolyPassHash want a cracker?

  • Impossible? Hmmm, I don't know about that. Chin Ho Kelly on Hawaii Five-0 can crack any password within a couple of minutes. I seen it.

  • ...it would take every computer on the planet longer to crack these passwords than the universe is estimated to exist.

    Let's hope they're not creationists.

  • by kye4u (2686257) on Thursday April 03, 2014 @12:02PM (#46650059)
    That problem is already solved. It is called SRP [stanford.edu] With SRP, even if the attacker has full access to the host, they cannot reverse engineer the passphrase.
    • Re: (Score:2, Informative)

      by Anonymous Coward

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

    • The chances are that we do not completely understand what they are doing. A major university making an announcement has a lot at stake when it releases such statements. Even monetary liability comes into play if someone suffers harm after using an "unbreakable" password and it gets broken. My greatest concern would be that our government is the author of such a scheme with a method in hand of getting through that password system. These days any encryption scheme may be tainted by government agenc
  • really? (Score:3, Interesting)

    by amaupin (721551) on Thursday April 03, 2014 @12:04PM (#46650093) Homepage

    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.

    Really? Okay, here are three NONrandom 6 character passwords that are stored using standard salted secure hashes:

    a44a6d60ebc202a7d296d82a7eac5748b7a93474c996e533795d769b297e613c
    5529ce75d4bf3bc7b488c8591906cc39bf5ac90feeeb9fbc278b0f98e03cafc6
    9de700d2bc4fa3ed30a3459a9cffd7785c10f465c5b9cfb4a83d417e9347f0f9

    Start your laptops, gentlemen. I'll even give you a hint. The first password is 123456. The second is abcdef.

  • by hawguy (1600213) on Thursday April 03, 2014 @12:10PM (#46650157)

    Is this really different than a "secret salt" that someone has to load into the server upon reboot?

    Instead of requiring N correct passwords to let the server build up its Shamir Secret Store data structure that lets it validate passwords, why not just have an admin type in the secret salt that is hashed with each password?

    Without that secret salt, the password file is useless. The secret salt can be protected by N passwords (or maybe it's a hash of those N passwords) just like the Shamir Secret Store data, the only difference is that instead of the server computing it the secret data, the administrator(s) types it in directly. If someone can compromise the server to get the secret salt (or can social engineer the administrator password(s), they can also get to the Shamir Secret Store data, so it doesn't seem any less secure.

    • Secret salt? Isn't that what we normally call a key?

      • by hawguy (1600213)

        Secret salt? Isn't that what we normally call a key?

        I don't know -- who is "we"?

        I called it a "secret salt" since it's not really an encryption key, it's just another input to the password hash function just as a normal salt is. But it's meant to be secret unlike a regular salt which is generally stored with the password hash.

        • Right, but Hash(data=(secret_salt || plaintext)) looks very much like message_authentication_code(key=secret_salt, data=plaintext).

          Not all keys are for encryption.

    • Is this really different than a "secret salt" [or key] that someone has to load into the server upon reboot?

      It's a way to require a quorum of administrators to load the key.

      why not just have an admin type in the secret salt that is hashed with each password?

      Because then you have to social engineer one administrator. With PolyPassHash, you have to social engineer n administrators.

      • by hawguy (1600213)

        Is this really different than a "secret salt" [or key] that someone has to load into the server upon reboot?

        It's a way to require a quorum of administrators to load the key.

        why not just have an admin type in the secret salt that is hashed with each password?

        Because then you have to social engineer one administrator. With PolyPassHash, you have to social engineer n administrators.

        Doesn't this part of my post solve than problem?

        The secret salt can be protected by N passwords (or maybe it's a hash of those N passwords)

        • PolyPassHash is a way of protecting what you call "the secret salt" with any n of m passwords, where 1 < n < m.
          • PolyPassHash is a way of protecting what you call "the secret salt" with any n of m passwords, where 1 < n < m.

            Ok, so that makes sense -- it really has nothing to do with protecting password hashes, it's just an "n of m split secret" algorithm.

  • by DarthVain (724186) on Thursday April 03, 2014 @12:12PM (#46650177)

    Crypto is being supplanted by a lack of rights.

    Ob. XKCD:
    http://xkcd.com/538/ [xkcd.com]

    Now a days you don't have to worry so much about some criminal beating you with a wrench, however you do have to worry about the NSA going to everywhere you actually store information online and forcing them to give the information over "voluntarily" by creating laws under some pretense and threatening legal repercussions, or by just doing it illegally anyway using the usual scare tactics. The same can happen to you personally, and they can pretty much throw you in jail for an infinite amount of time until you produce the password in question anyway.

    Anyway criminals are NOT brute forcing huge lists of passwords in the first place. They either take advantage of terrible security in the first place (Hey lets store all the passwords in an unencrypted text file which anyone can access if they know where to look!), software vulnerabilities (Hey your password is super safe, too bad there is that gaping security flaw that lets people bypass passwords altogether!), or social engineering (Hey sure I will give out your password, I'm an IT guy that gets paid 10$ an hour and I really don't give a shit anyway).

    So while in an interesting sort of puzzle way this is neat, the actual protections it will afford you is probably very little.

    • by DarthVain (724186)

      Also I forgot about what I call the FB rule.

      Your password is super safe and invulnerable. However you signed a EULA (that is 862 pages long, stored in some obscure location, that can be changed at will) by glancing at it for about 5 seconds to find the next button, that basically gives the rights to all the information you were protecting in the first place, and your first born son, to the company that stores the information, who can and will sell it all to the highest bidder anyway.

    • The point of PolyPassHash is that instead of torturing one administrator with a $5 wrench, you have to torture n administrators at the same time with multiple $5 wrenches. This pushes the torture further into organized war crimes as defined in applicable treaties.
    • Now a days you don't have to worry about [small sky falling], but you do have to worry about [large sky falling].

      Once upon a time, real engineers solved the solvable problems in whatever order solid solutions presented themselves, so that presently unsolvable problems evolved into greater relief.

      I thought it was a good system. Good engineering, RIP.

  • Can someone explain it in terms of a car? Or perhaps two cars, with Alice in one and Bob in the other.

    • Bob's car won't start until Alice blows his Breathalyzer, because Bob's a drunk.

      Seriously it's more like Bob's key won't start Bob's car, and Alice's key won't start Alice's car, unless both Bob and Alice turn their keys at the same time. The keys have transponders in them that talk to each other.

      Therefore, you can't make an unauthorized spare key by examining Bob's lock - your unauthorized key has to match both Bob's lock and Alice's key.

  • .... No results found.

    ~Sticky

  • "does an organization have any excuse if their password database is disclosed and user passwords are cracked?."
    Yes: 1. hiring incompetent morons
    2. insufficient budget for IT work
    3. idiot contractors/vendors
  • Of course. They wrote it in Scheme and used call/cc wherever possible. Now nobody can get in because nobody can understand it, not even the guy who wrote it.

I judge a religion as being good or bad based on whether its adherents become better people as a result of practicing it. - Joe Mullally, computer salesman

Working...