1. 9

  2. 8

    https://rmmh.github.io/abbrase/ walks Markov chains. Memorable and doesn’t lose entropy.

    1. 3

      That method would still need 12-13 words to get the 127bits of entropy. But I like that it’s helping with her total length of the final password without losing entropy.

      1. 4

        I’m curious where her 128-bit requirement came from. That’s a typical minimum these days for symmetric crypto keys, but that assumes a lot about the threat model and the attacks that will be mounted against the crypto. A password has to handle two threat models:

        • Online attacks. If someone has access to the authentication interface for the thing that you’re trying to password protect, can they guess your password?
        • Offline attacks. If someone leaks the password database, can they generate your password from the salted hash?

        For online attacks, 50 bits of entropy seems like plenty. If you limit logins to one per second with a given username, then it would take 2^49 seconds on average to guess a 50-bit password. That’s almost 20 million years, so it’s far more than you’d need for this threat model.

        For offline attacks, assume hash is properly salted and so you have to attack each password independently. Most password hashing algorithms are designed to be slow (and difficult to implement as fixed-function circuits). If you assume that the person has been incompetent and used SHA256, then this starts to be a bit worrying. A single GPU will crack a 50-bit password in around 10 days on average (using the 622 million SHA256 hashes per second from Some Guy On the Internet). If they’re using Argon2, this is a lot better. It looks as if GPU hash rates Argon2 (which is designed to not get much speedup from GPUs or cheap fixed-function silicon or FPGA) are still under 20,000/second. That means that we’re looking at about 8-10 years of GPU time per password for offline attacks. Of course, these attacks are intrinsically parallel and so if you wanted crack a single specific password then you’d be able to just throw more GPUs at it. If you’re using a cloud provider, one GPU for a year and 365 GPUs for a day cost the same, so you might as well throw a load of them at the problem. Using Azure’s spot pricing, cracking a single 50-bit Argon2-hashed password would cost a bit under $10K.

        Next comes the security economics bit: If it would cost $10K to crack your password, what is the value of the stuff that it would gain access to? If it’s a lot more than $10K, then you should worry about your 50-bit password if offline attacks are in your threat model. Typically; however, they are not. For high-value targets, the password is provided to some isolated hardware / software that stores the real encryption key. For example, most of my day-to-day work use is protected by a 6-digit PIN that is used to authenticate me to the TPM. That PIN is completely useless if you steal it unless you also steal the TPM. Once I’ve logged in, the TPM will provide RSA signatures with a key that the TPM is designed to make it impossible to extract. To impersonate me to a remote system, you’d need to extract that key, not my password. At that point, it’s significantly more secure than the OS kernel and so any sensible attacker would look for a browser or OS exploit to compromise the endpoint. Adding more entropy to my password would not make life any harder for an attacker.

        All of that said, I really like the abbrase model. It’s a shame that it can’t actually be used in most places as-is, because so many things require you to enter a password with a mix of upper-case, lower-case, numbers and symbols. I suppose you could just add a A1; on the end of every password…

      2. 1

        That’s interesting! I think you could actually have a system that has some of the advantages of both of these methods, if you made an alternative diceware list with a way of uniquely shortening each word. i.e. one reason diceware is nice is that you can use it without relying on a prng. I suppose you could also make a version of this app that takes any sequence of triplets and mnemonizes them, which would be another good way to do it if you don’t mind typing your password into an app once (which I usually don’t mind too much)

      3. 3

        It’s a good idea but I think 13 words is still pretty crazy. It’s not only a lot to remember, you also need to type a lot. Also, as OP described, even in the best case scenario where people use a password manager, they still have to remember at least two to three passwords.

        On a side note: I wasn’t able to open the link for the entropy calculation method.

        1. 2

          It’s definitely a tradeoff; you can of course use the same trick for shorter passwords.

          I changed the link to point at dropbox instead of overleaf; hopefully that works better.

          1. 2

            How often do you type your password? Once a day? Once an hour? I think that that helps definite what ‘too long’ is.

            If you have a 13 word password that you only type once a month when you restart your computer, and a 6 word password to unlock the second lock on your gpg key every 4 hours, it’s different than a 10 character password you have to retype every 10 minutes.

            1. 1

              I see were you want to go but the catch is that the passwords you type the least would then also the hardest to remember. Not a good combination.

              1. 1

                That’s where the tradeoff between memorability and shortness comes in.

                Passwords I type very frequently are generated with about 5 bits per character by excluding pairs on a qwerty keyboard that are hard to type together, passwords that I type less frequently are much longer diceware type which are easier to memorize with infrequent use. Passwords I don’t type at all are just 100 bits or so of base64