I just have a python two-liner that picks four random words from /usr/share/dict/words and downcases them. This is sufficiently entropic for my purposes:
print(' '.join([w.strip().lower() for w in random.sample(list(open('/usr/share/dict/words')), 4)]))
Someone I can’t recall coined the quip that while password policies are stuck in 70s mainframe land, the technological sophistication of attackers use the latest machine learning and statistical analysis tools.
The XKCD panel is no longer secure advice, since attackers learned how to aggressively mutate and statistically analyze large password datasets. On massive data breaches they are above 95-98% recovery rate from hashed passwords.
The state of the art is if it is a combination of human meaningful words and some additonal mutation and a few random characters on top, it’s already within reach of the people reversing hashes. (Which is the threat model, credential stuffing, not someone trying to brute-force a login).
This is why security researchers are pushing for password managers that generate non-human-meaningful 18+ character random passwords per service.
Can you explain this more? How does statistical analysis help with the entropy of words more than with the entropy of characters? Remember (I’m sure you do, but for onlookers) than in the XKCD panel we’re not mistakenly counting each letter as entropically meaningful but only the words vs the size of a reasonable dictionary. So a dictionary attack is the assumed vector, I’m curious what new statistical tools improve on this attack.
I also would like to see this explained. Regarding password managers and credential stuffing: using a 6-word passphrase (the recommended length for current required entropy levels) doesn’t mean you can keep using the same passphrase for every service. You still need a unique correct-horse-battery-staple-defection-epilogue passphrase for each service. But when you need to type a password from your password manager and can’t use autotype, it’s easier to correctly type a 6-word passphrase than PIXROU8i+00((AJM4s$$.
if you’re generating passwords based on a strongly random source, of course it doesn’t matter if you’re using the randomness to generate random characters or select random words out of a large dictionary, overall entropy matters.
Contrary to the small-print text in the xkcd comic, offline cracking attacks are the ones to worry about, not online guesses against a service.
How much entropy is enough? That depends on the way a particular service is storing the passwords. If you’re using a password manager then it’s a mute point, you might as well use a strong 20+ character autogenerated password per service. If you’re using a memorable passphrase without a password manager though, the lowest common denominator hashing/salting method across all services the password is shared with is the one you want to protect against. It’s unlikely that you’ll ever get hard confirmation from any service about their password storage procedures, especially from services that are at the most risk from data breaches (the ones not too much on top of things). Recent versions of GPU-based password cracking benchmarks range from 100 Gigahashes/s per GPU to a couple thousand for more hardened password-storage methods. If you can attack at 100Gh/s instead of a thousand guesses per second, the correct-battery-horse-staple example would take 175 seconds to find, assuming you know the dictionary it was generated from.
This was all assuming that people use strong randomness as a source of their passwords. Most people still don’t do that and password cracking tools learned long-ago to account for all the clever tricks anyone could ever think of to generate passwords from various dictionary or other methods (and therefor vastly narrow the search space).
The biggest problem with the xkcd comic therefor is to suggest that you can ever remember passwords. I guess it’s more important that you use a different non-related password per service than the individual entropy levels of the passwords, but to do 1. you already need a password manager so no point in using weak passwords. I agree with the narrow point though that using a long passphrase composed from common words might be easier to type from a phone.
I should have added – you need to use a sufficiently long, memorable passphrase for your password manager, so there is always one passphrase that has to be memorable. You will probably have to memorize your workstation/laptop passphrase, too, unless you want to keep looking it up on another device (your phone), since the local password manager is not available while you are logged out/screen locked. And it’s likely to be worthwhile to have a memorable passphrase for some of your most used services, such as email. So that’s maybe three or four passphrases that you need/want to memorize, and which should therefore be diceware-or-similar.
For everything else, I don’t really care whether I’m using a diceware passphrase or a random-characters passphrase, since it’s in my password manager. But even then, if the password manager offers the option to generate diceware passphrases, I will use those, because they are easier to type and visually verify.
If you somehow learn that github user ken has password p3ssw4rd, try that username and password on every site you’ve heard of, stupidly. Most people reuse passwords, see? So you stuff the github credentials you learned into facebook’s login form, linkedin’s, every service’s login form.
Data breaches are now so common and wide-ranging (just check the billions of records in https://haveibeenpwned.com) that if you’re not using a password manager with individualized password for each service, then the likelihood is very high that the few passwords people inevitably reuse across many services has been already part of a data breach.
So nefarious people just take the data dumps with the cracked passwords (or email, password combinations) and just try to login to other services with the same username/password combination. With a quite high success rate.
To combat this there are two actions people can take:
use a different password per service (only really feasible with a password manager)
use a strongly random, long password that resists offline cracking (only really feasible with a password manager)
Thanks! I am familiar with the concept, but the specific term was unknown to me.
I personally use a password manager, and I think one should probably be integrated in services like Google or Apple IDs. Perhaps banks can include a subscription for one as part of the fee for having an account - it would probably help a lot with fraud, so could be a net positive for them.
This is true, and I use the above to generate memorable nonsense for the answers to security questions, and use my password manager’s maximally entropic random generator for everything else.
Ok so my biggest problem with this is the “force symbols” section.
Drawing from urandom derives high-entropy randomness, represented as characters. Entropy in this sense is a measure of possibilities: a password drawn at random from a space with many possibilities is hard to bruteforce.
Re-sampling until you get symbols actually decreases the entropy, although likely not by a problematic amount. This probably what password managers are doing, but it’d be nice to discuss in a post digging into this.
Lastly, it’s important to note that RC4 is not secure, but arc4random on OpenBSD no longer uses it.
I think this solution is subtly broken on utf-8 systems as /dev/urandom is not very likely to generate valid utf-8 sequences. It looks like GNU tr just reads over that, but FreeBSD tr for example doesn’t (or at least, it didn’t use to).
I actually wrote a thing about this a few years ago: https://arp242.net/weblog/generate_passwords_from_the_commandline – I should probably update that article a bit, as well as mention that LC_ALL=C will work (guess I didn’t know about that back then) as well as update the writing style a bit (every time I read something I wrote a few years prior I think my English is terrible 🤔)
That’s a good point. Is that really an issue though? In UTF-8, all ascii characters keep the same value, which means that tr will be able to read them just fine. It might never encounter any UTF-8 value, but is that really an issue?
Well, your command won’t work on some platforms, like FreeBSD and OpenBSD (at least, it didn’t the last time I tried it, around 2013-2014).
In UTF-8, all ascii characters keep the same value, which means that tr will be able to read them just fine.
Yes, but only for the first 7 bits; when the highest bit is set you run in to the multibyte territory and utf-8 will try to decode it, which will fail for most random streams.
It ran fine on my OpenBSD 6.4 box. I suppose (hope!) it would be the same on FreeBSD now.
Great article though. Passing it through strings is a good idea.
Is there some problem with the solution found on stackexchange? I use it as the default on Linux, and it seems really simple and straightforward to me? (For letters-only, just use the simpler tr -dc 'A-Za-z0-9')
I just have a python two-liner that picks four random words from
/usr/share/dict/wordsand downcases them. This is sufficiently entropic for my purposes:You can also do this with Bash directly from the terminal:
for i inseq 1 10; do nice_dogs=shuf -n 5 /usr/share/dict/words | tr ‘\n’ ‘-’&& echo $nice_dogs$RANDOM; doneExample output:
For those copy-pasting:
Like in https://xkcd.com/936/ ?
Someone I can’t recall coined the quip that while password policies are stuck in 70s mainframe land, the technological sophistication of attackers use the latest machine learning and statistical analysis tools.
The XKCD panel is no longer secure advice, since attackers learned how to aggressively mutate and statistically analyze large password datasets. On massive data breaches they are above 95-98% recovery rate from hashed passwords.
The state of the art is if it is a combination of human meaningful words and some additonal mutation and a few random characters on top, it’s already within reach of the people reversing hashes. (Which is the threat model, credential stuffing, not someone trying to brute-force a login).
This is why security researchers are pushing for password managers that generate non-human-meaningful 18+ character random passwords per service.
Can you explain this more? How does statistical analysis help with the entropy of words more than with the entropy of characters? Remember (I’m sure you do, but for onlookers) than in the XKCD panel we’re not mistakenly counting each letter as entropically meaningful but only the words vs the size of a reasonable dictionary. So a dictionary attack is the assumed vector, I’m curious what new statistical tools improve on this attack.
I also would like to see this explained. Regarding password managers and credential stuffing: using a 6-word passphrase (the recommended length for current required entropy levels) doesn’t mean you can keep using the same passphrase for every service. You still need a unique correct-horse-battery-staple-defection-epilogue passphrase for each service. But when you need to type a password from your password manager and can’t use autotype, it’s easier to correctly type a 6-word passphrase than PIXROU8i+00((AJM4s$$.
A couple of things worth mentioning here:
I should have added – you need to use a sufficiently long, memorable passphrase for your password manager, so there is always one passphrase that has to be memorable. You will probably have to memorize your workstation/laptop passphrase, too, unless you want to keep looking it up on another device (your phone), since the local password manager is not available while you are logged out/screen locked. And it’s likely to be worthwhile to have a memorable passphrase for some of your most used services, such as email. So that’s maybe three or four passphrases that you need/want to memorize, and which should therefore be diceware-or-similar.
For everything else, I don’t really care whether I’m using a diceware passphrase or a random-characters passphrase, since it’s in my password manager. But even then, if the password manager offers the option to generate diceware passphrases, I will use those, because they are easier to type and visually verify.
I am not familiar with this concept, what is the definition of this?
If you somehow learn that github user ken has password p3ssw4rd, try that username and password on every site you’ve heard of, stupidly. Most people reuse passwords, see? So you stuff the github credentials you learned into facebook’s login form, linkedin’s, every service’s login form.
Data breaches are now so common and wide-ranging (just check the billions of records in https://haveibeenpwned.com) that if you’re not using a password manager with individualized password for each service, then the likelihood is very high that the few passwords people inevitably reuse across many services has been already part of a data breach.
So nefarious people just take the data dumps with the cracked passwords (or email, password combinations) and just try to login to other services with the same username/password combination. With a quite high success rate.
To combat this there are two actions people can take:
Thanks! I am familiar with the concept, but the specific term was unknown to me.
I personally use a password manager, and I think one should probably be integrated in services like Google or Apple IDs. Perhaps banks can include a subscription for one as part of the fee for having an account - it would probably help a lot with fraud, so could be a net positive for them.
This is true, and I use the above to generate memorable nonsense for the answers to security questions, and use my password manager’s maximally entropic random generator for everything else.
Yep! And it has the added advantage of being much easier to type on e.g. a phone virtual keyboard than a shorter but symbol-heavy password.
Maybe even shorter: jot -rcs ‘’ 20 33 126
:)
Not really comparable, though. I’d do something like this from the shell (fish syntax):
out of the current top 10 distros:
https://distrowatch.com
Debian is the only one that has “jot” available, and its called “athena-jot”:
https://packages.debian.org/stretch/athena-jot
so this suggestion is not helpful.
Didn’t see the Linux tag, my bad.
Is there any reason to not just use
pwgen? I use it either directly or from withinpass.maybe because it’s not in base
Ok so my biggest problem with this is the “force symbols” section.
Drawing from urandom derives high-entropy randomness, represented as characters. Entropy in this sense is a measure of possibilities: a password drawn at random from a space with many possibilities is hard to bruteforce.
Re-sampling until you get symbols actually decreases the entropy, although likely not by a problematic amount. This probably what password managers are doing, but it’d be nice to discuss in a post digging into this.
Lastly, it’s important to note that RC4 is not secure, but arc4random on OpenBSD no longer uses it.
If you want to do the same on any POSIX system, you can use
tr(1):Note that this one doesn’t enforce any number of symbols though. It only replace the calls to
jot | rs, which are not available on every POSIX system.edit: fold at 12 chars to comply with original post.
I think this solution is subtly broken on utf-8 systems as /dev/urandom is not very likely to generate valid utf-8 sequences. It looks like GNU tr just reads over that, but FreeBSD tr for example doesn’t (or at least, it didn’t use to).
I actually wrote a thing about this a few years ago: https://arp242.net/weblog/generate_passwords_from_the_commandline – I should probably update that article a bit, as well as mention that
LC_ALL=Cwill work (guess I didn’t know about that back then) as well as update the writing style a bit (every time I read something I wrote a few years prior I think my English is terrible 🤔)That’s a good point. Is that really an issue though? In UTF-8, all ascii characters keep the same value, which means that
trwill be able to read them just fine. It might never encounter any UTF-8 value, but is that really an issue?Well, your command won’t work on some platforms, like FreeBSD and OpenBSD (at least, it didn’t the last time I tried it, around 2013-2014).
Yes, but only for the first 7 bits; when the highest bit is set you run in to the multibyte territory and utf-8 will try to decode it, which will fail for most random streams.
It ran fine on my OpenBSD 6.4 box. I suppose (hope!) it would be the same on FreeBSD now. Great article though. Passing it through
stringsis a good idea.Is there some problem with the solution found on stackexchange? I use it as the default on Linux, and it seems really simple and straightforward to me? (For letters-only, just use the simpler
tr -dc 'A-Za-z0-9')