1. 16

  2. 4

    I think this is good advice but only three words?! I’m a fan of using random words for important passwords but I use six, per Diceware recommendations: https://theworld.com/~reinhold/dicewarefaq.html#howlong

    FWIW 3 random words gets you about 38 bits of entropy in Diceware, or 6-7 ASCII characters. That’s assuming words drawn from a known dictionary of ~7800 words; this article doesn’t really talk about the dictionary which makes me think it’ll likely be worse, like the ~5000 words a person commonly thinks of.

    The article does say the 3 words are “strong enough for many purposes, and can be remembered much more easily.” That’s probably a reasonable tradeoff for all the stupid websites that require a password to do things that really you don’t care if they’re secure (like, say, commenting on a crustacean-themed tech discussion forum.) Six words are not easy to memorize or type; I’ve been using one passphrase for 3 years and I still mix up the word order or mistype it one time in five.

    1. 4

      Three words works for people, and it’s advice people can follow.

      Going brute force on a password means you have quite a difficult job, even if technically the entropy is lowered. The entropy only matters if the general form of your password is known.

      1. 1

        Yeah that tradeoff makes sense, just surprised at it at first. Brute forcing also seems to be much less of a threat for most website passwords. In the old days you had a copy of /etc/passwd, the encrypted form of the password, so you could run a brute force attack against it offline with millions of tests a second. These days the naive attacker only has the HTTP interface and is probably rate limited in some way, hundreds or thousands of tests a second at best. (Yes, password databases get stolen, but if a site has been compromised that much there’s a lot more to worry about than your password there being brute forced).

        1. 3

          Yes, password databases get stolen, but if a site has been compromised that much there’s a lot more to worry about than your password there being brute forced

          Unless it’s just one character off from your bank password, which is true for an awful lot of people.

          1. 2

            Unless it’s just one character off from your bank password, which is true for an awful lot of people.

            I can’t even sign into my bank using a password, the weakest authentication method is a hardware challenge-response device.

            We (as in the nation of Sweden) have an universal authentication app for multiple platforms (iOS/Android plus a Windows client) called BankID that is normally preferred by all involved (and issued by the banks), banks, companies and government. It’s pretty neat.

      2. 1

        Back in the day, passwords were stored hashed with something pretty weak. It was feasible to create a rainbow table that gave a valid password for every single hash. Systems moved to counter this by providing a salt, so you could still create a rainbow table for a single system, but it wasn’t reuseable.

        The hash functions themselves came under scrutiny and folks first moved towards well-known cryptographic hash functions that guarantee uniformity of output and so on. These hash functions were typically designed for message integrity checking. That was a problem because one of the goals was that you should be able to compute hashes quickly. That helps the attacker a lot. If you can compute millions of password hashes per second on a single machine then you need a lot of entropy to have a good password.

        Modern password hashing algorithms such as Argon2 are specifically designed to be computationally expensive and difficult to implement in hardware (or offload to the GPU). If a system is using Argon2 then the moderate configuration from something like libsodium takes about 0.7 seconds to compute on a modern i7 with 64 MiB of RAM allocated to the hash function. If you’ve got 38 bits of entropy then it will take you an average of 2^37 tries to find a collision. That works out at about 26,724,241 hours of CPU time. With spot pricing, you can get about 96 core-hours per dollar, so that works out at $280K to crack one password today. If you’re the target of the NSA, they almost certainly have dedicated Argon2 hardware (it’s difficult to implement in hardware, but not impossible. In particular, it relies on random memory access and so a manycore system with a load of memory and in-order cores with SMT that can execute another thread while waiting for data from memory will probably outperform a general-purpose CPU) that can crack passwords more cheaply, so it is probably in the range of $3-30K per three-word pass-phrase for them.

        If you use an English word list, which typically contains around 60K or more words to generate 3 words that you ask people to remember, then you get at least 10 bits more entropy, so increase the numbers in the above paragraph by a factor of about a thousand. You might want to exclude some of the words that are in much shorter word lists (or, at least, combinations that comprise only words from the shorter lists), but you need to be careful to not remove too many possible cases if you do this.

        There’s also the longevity factor to consider. Computers generally get faster over time. We’re not seeing a doubling of performance every year, but we are seeing a lowering of cost and so a password that costs $1m to crack now may cost a few thousand dollars in ten years. If you’re using the password to log into a live system, then they can periodically tweak the parameters of their password hash function over time and delete the old versions. This means that if the password database is compromised then you have a reasonable window to generate a new password before a reasonable attacker could be assumed to have cracked the old one. If you’re using the password for a key-generation function for a long-lived key (e.g. to protect encrypted data) then you need to think about what happens if an attacker in 10 years decides to try to decrypt your data from now. Five words from a word list of 111K words gives 84 bits of entropy, which is unlikely to be computationally feasible for quite a long time. You get about the same number if you take the 143K words list and remove everything from the 27K most common words list.