shuf -n 4 /usr/share/dict/words
shuf --random-source=/dev/urandom -n 4 /usr/share/dict/words
[1] https://www.gnu.org/software/coreutils/manual/html_node/Rand...
[2] https://github.com/coreutils/coreutils/blob/v8.5/gl/lib/rand...
[3] https://github.com/coreutils/coreutils/blob/v8.32/gl/lib/ran...
Edit: As ThA0x2 points out in a reply, the latest version of shuf uses /dev/urandom to generate a default nonce, which vastly improves upon older versions. As long as your version of coreutils is at least 8.6 or later and your OS has /dev/urandom, the default should be fine. If you don't have /dev/urandom, even the latest version of shuf (version 8.32, as of June 15, 2020) will still default to an insecure nonce.
In any case, I expect it's much harder than a random "free password gen!" website saving results on the sly (... which is meant to be mild criticism of your framing, but not your recommendation :-p).
https://github.com/coreutils/coreutils/blob/v8.31/gl/lib/ran...
Your "--random-source=/dev/urandom" line is superfluous. My original line is as secure as yours.
The main objection I have to sites like this is that they encourage people to use a random untrusted site to generate a password for, say, their bank account.
no thanks.
That should meet pretty much any password requirement, be virtually impossible to guess or brute force, and you won't have trouble remembering it (because you don't have to!).
Lol I wish. Almost all of the important sites I use, like various bills and loans, use terrible password schemes. One even, until recently, enforced an 8 character limit! I think they raised it to 16 iirc. Oy.
Hell, even the company I work for frequently fails my password generator settings. The arbitrary character requirements of my ~20 character password would sometimes not be satisfied when I was creating accounts in our dev system/etc. Which is annoying as hell, but I can't convince management, because our users (older) tend to use some of the worst passwords out there.. so I can understand where it's coming from.
Security & UX is hard.
All it takes is the one time, for whatever reason, that you have to type in a string of a few dozen random characters by hand on a phone keyboard or something because you're on a new device, or cut and paste is disabled, or whatever, and you'll understand why long random passwords should be reserved for web servers and so on and never used with consumer web applications like a hotel reservation program, or rental car app, or similar.
It doesn't have to be all or nothing and is probably better if it isn't.
But randomness are not enough, it's possible the first generated version correlate with your preference and that situation does not really matter why are you stopped generating new password.
Predictability of this scheme very good, because the strict rules. All implementation using common english words. For words smaller length, easy spelling, less ambiguity are preferred. Mixing nouns verbs and adjectives are more meaningful, order also adds more meaning. Word count very limited. Preference on the separator character also very rigid. Personal preference more known, because hidding your preference on all english words very hard and mostly unconscious.
Eg the scheme doesn't do its job well if you don't know the word, so the dictionary can be reduced by that much
Recently, I decided to package it up with a nice domain name and publish it in hopes that it would be useful to others.
80% of my passwords are just line noise, because they live in a keepass database. 20% (workstation account logins, etc) are diceware.
It doesn't take long to type a wholly-memorized sentence.
A passphrase, as opposed to a password, has spaces between each word.
If you added those it would be easier to read, especially for mobile, if you used a multiline textarea, because the generated content isn’t fully readable at a glance. (Or don’t use a form input field at all — just put the passphrase in a div so the word breaks flow normally.)
Currently I use and recommend https://preshing.com/20110811/xkcd-password-generator/
What it does well on:
The source code is open source licensed. Passwords are generated in the client, not on the server. The generator is random. The generator is cryptographically secure. The generator is unbiased. Mobile devices are supported. There are no JavaScript trackers loaded on the page. The site is not calling out to external resources without SRI.
Unfortunately, by only choosing 4 random words, the security margin of the passphrase is 52 bits (13 bits per word). This is practical for a hobbyist password cracker to exhaust in an offline attack. The security would be better if 6 random words were chosen instead.
Audit: https://docs.google.com/spreadsheets/d/1ucaqJ4U3X3nNEbAAa06i...
The default was chosen as 4 words due to usability concerns with longer passwords or more obscure words, but it is adjustable. The strength meter is yellow at 4 words to indicate the less-than-optimal entropy, but I felt it was better than turning a new user off by making it too hard to remember. But that's a decision I plan on revisiting.
If you are security conscious, you can save a more secure default for yourself (in local storage, nothing is ever transmitted to a server).
I would recommend the default be 6 words, and let people choose down to 4, but not lower. At last that way, users know what a "secure default" looks like. Granted, it breaks the four-word "correct horse battery staple" XKCD format, but Randall was in some error with that comic anyway.
Even if the site knew for certain that you had used one of the passwords, they would have no idea where you used the password, and they wouldn't know your username or other credentials.
They might not even have any way of accessing the system you're putting the password into.
I'm sure a lot of people will use these sorts of sites to generate a whole bunch of passwords, and not even use any of them.
I agree, the risk is minimal. Nevertheless.. security, heh.
At some point 1Password dropped that, replacing it something similar to "correct horse battery staple". It's words (3-10) separated by hyphen, space, period, comma, or underscore. E.g., "plasma.haggis.arrange.stultify".
I think your site works well on selling itself if you assume the audience is coming from HN. From what I have observed, your site does not market itself well to a typical corporate IT dept who are not all programmers.
I think if we want to promote wider adoption of this good password technique, we'll need a different approach.
This is not a criticism-- You've done a job I admire. I think I might fork it and make another version that is approachable to a wider audience. Thank you!
62^12 = 1e21
10 000^5 = 1e20
The problem is you not using a word generator and instead relying in your invention, most of the people will use top 5000 words (5000^5 = 1e18), imagine you can even lock one of the words (a color maybe?).So this way of thinking might be good if you know what you are doing and use uppers and lowers and symbols, if not, it is actually a bad advice.
$ shuf --random-source=/dev/urandom -n6 /usr/share/dict/cracklib-small | paste -sd-
circulant-conjured-reigning-buzzed-awaiting-typifiesKeePassXC has a passphrase generator, although it doesn't use the Diceware list as far as I know. https://keepassxc.org/images/screenshots/linux/screen_006.pn...
EDIT: Love the simplicity of https://correcthorse.pw/, good work!