Show HN: Correct Horse Battery Staple password generator | Hacker News Reader

Show HN: Correct Horse Battery Staple password generator

correcthorse.pw

44 pointsquantum593 comments

I audit web-based password generators as a hobby, and this one does well.

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

Thank you for the audit!

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

No problem. I dig the project. Very cool.

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.

Can someone explain to me why 1password doesn't have something like this built in? You can use words, or random/symbols, but not both. Which fails miserably every time you're faced with some sort of silly password requirement to have a symbol and a number and a capital or whatever.

Lately I'll use the word-based recipe in 1PW and add in a capital letter, special character and number before saving. This should be very easy to automate, I too am surprised they haven't offered this yet as an e.g. "salted passphrase."

Yeah, I find myself having to generate a passphrasea and then change the capitalisation and add a number.

Passphrases are easy for people to remember, but if you have a password manager, you're better off getting it to generate a 50+ character random password (including uppercase, lowercase, numbers and symbols).

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!).

> you're better off getting it to generate a 50+ character random password (including uppercase, lowercase, numbers and symbols).

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.

I heartily disagree.

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.

While I would love to use something like this, almost every site I can think of enforces worthless password rules like "Must include number, letter, special character" etc which effectively blocks these types of passwords.

I don't think the password managers do, for master passwords. So if you ever consider it, you can set your master password to a strong one generated here and let the pw manager generate those 30 char random strings that fill all of the requirements for the other sites.

Much like /u/hprotagonist above, I tend to use passwords like this for my pw manager, full disk encryption, PGP, etc. where I get to set the rules. Web sites or other uses outside my control get a randomly generated string of varying length.

It doesn't have to be all or nothing and is probably better if it isn't.

You can always 1337 the password.

Just add A1! to the end of every password

There is an option on correcthorse.pw to add a number and/or a special character as needed.

Problem with generators and this scheme, they allow regeneration. Most people not using the first version, they generate a new until they like it enough to stop, which is not that random anymore as they think.

So you're saying that generating a new password looses entropy?

Choosing is the problem here -- it's now only as random as your preference

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

On the other hand, I'd wager that the set of words that you can recognize is vastly larger than the set of words that you're likely to come up with on the spot. Hence, using a generator would still result in higher entropy then trying to come up with a password yourself.

Random numbers picked by humans are notoriously biased. I'm guessing it's even worse when you ask them to come up with random words.

Yes, if the regeneration depends on your preference of the generated words, the words order or link between them. The individual generations independent from each other, so if your choice – how many regeneration you do - not depends on the generations outcome, for example on your birthday date or favorite number, their randomness are equal.

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.

A mild amount of regeneration doesn't hurt, though. If you generate 4 and pick your favorite, you've shaved less than 2 bits of entropy off.

It's just a bare minimum that you reduced, if you add some preference it's worse than that. I did some test, maybe I'm just lucky, but i got password with a word starting with b at the 3rd generation, and i got adjective-noun pair in that order at the 5th generation.

> It's just a bare minimum that you reduced

No, it's the -maximum- that I reduced entropy by. If I choose randomly from 4 possible passwords, I've shaved off --no entropy--.

If I choose with a strongly predictable preference (say, everyone knows I'll pick the password that's first alphabetically) I've shaved nearly 2 bits off the probable search space: you probably only need to look in the first 1/4th of the search space.

Choosing with some subtle, individual preferences is something inbetween.

> with a strongly predictable preference

No, your example has nothing to do with preference, your method (picking out of 4) just less random than picking from one (the first).

Preference is, when certain passwords more likely to be picked than others or at those passwords less likely to be stepped over to generating a new one. Wtih strong preference you regenerate until you got that preferred password, for example you prefer short words and the attacker know that, at first trying combinations with short words has better chance to cracking the password.

You're just talking past me, bro. Regenerating and picking your favorite from a few is reasonable and isn't a big entropy penalty (the penalty is easily bounded).

Infinitely re-rolling until you get the exact phrase "correct horse battery staple" obviously has a severe entropy penalty, and this is not a reasonable course of action.

> You're just talking past me, bro.

Sorry for over explaning, but I feel it necessary.

Sticking with your example and making more formal. Name it pick function and let its three modes, random, deterministic and preference. In the random mode, the probability of picking one from the inputs are equal to picking to any other. In the deterministic mode, with the same inputs the function always picking the same and the probability of others are zero, but if the inputs change or any input, it could change the picked one. In the preference mode the function not just picking one, but making a sorted list of the inputs. In the preference mode, changing one input not changing the others sorting. In this mode using pick function on several inputs you got some information about the inputs overall probability distribution aka entropy (more precisely entropy is the measure of that).

The important from this, determinism not imply preference, but not random also. Cryptographic hash functions doing the extreme version of this determinism, the output is well "distributed", but not random. (PS: Sometime that characteristic called pseudorandomness, that is how PRNGs works with random seed)

Deterministic pick applied to random pick just less random than random pick alone on the same set, because random pick has the maximum of the entropy and adding some deterministic part just reducing that. But most people not picking with a well distributed deterministic function in their mind, more likely they pick with preference, which is I think much worse. So, that why I call it the bare minimum.

Background: I liked the xkcd-style password generation scheme as it was easy to remember, but existing generators online (that I could find, at least) all use Math.random() or other cryptographically insecure random number generators. While an actual attack on the RNG seems far-fetched, the very idea doesn't sit well with my crypto nerd side. So I decided to create my own that uses a CSPRNG that I can trust. This was a while ago.

Recently, I decided to package it up with a nice domain name and publish it in hopes that it would be useful to others.

What about https://www.random.org/? Why even use a PRNG if you can have the real thing?

Because instead of just trusting your system, you'd also have to trust an external service to remain honest. CSPRNG is widely deemed acceptable for use as key material (unlike standard PRNGs), so there is no reason to add an external dependency.

Further, sufficiently seeded cryptographically secure RNGs are indistinguishable from true random white noise, so from a practical perspective, there is no point to require "true random".

That seems like a false dichotomy to me unless I were to truly understand the PRNG.

There is always the risk that such a website is, or could become, malicious and save generated numbers for future attacks; or, it could suffer from a hardware, software, or environmental issue that reduces entropy. While I would not fully trust a website-generated random number for anything important; you can XOR a number from a website such as www.random.org with a number from your system's PRNG so that you don't have to fully trust either. Even better, you can XOR again with some dice-generated numbers, your own custom PRNGs, or whatever else you can think of. That way, as long as at least one subset of your sources has sufficient entropy, you are safe.

Nice idea. Not sure I'm going to remember the 9,999 word password it just generated for me :)

So we are really getting passwords from remote hosted websites? Are people really about to copy, paste and use these right out of the browser?

What is the risk exactly?

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'd imagine the risk is pretty great, for the same reason I wouldn't paste a password here that I use. Sure, you may not know who I am, but if you were the site itself you get a ton of information on me.. which is more than I'd like you to know if you _also_ know one of my passwords.

I agree, the risk is minimal. Nevertheless.. security, heh.

The site doesn't know the password, though-- it's generated clientside.

Will you be inspecting the code every single time it loads to ensure that has not changed? You are receiving this code from an untrusted 3rd party every time you visit. There is a big difference to trusting a known entity like lastpass, 1password, etc, all of whom are vulnerable to supply chain attacks. It is another thing entirely to trust a random website on hackernews.

Payload decoders and password generators are some of the biggest honeypots out there. Combining this with an attack taking advantage of hidden form autofill, you could gain quite a bit of information to go along with that password.

If I were to use it, I'd probably just pull my own copy off github.

If I were to recommend novices to use it-- I'd tell them to use a password manager locally, and something like that to generate a secure password to get into their own machine locally / get into their password manager-- which mitigates most of the risk if it turns rogue.

well then you wouldn't be using this or any other website, and this entire conversation would be moot :).

Nice work!

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

Yup. With the ability to add a separator (like a space, -, .) I'd switch over to this.

Currently I use and recommend https://preshing.com/20110811/xkcd-password-generator/

Good idea, just added separators to the website.

You could(/should) add space and make it the default separator :)

Space support is included. You can save it as the default option if you want.

I just updated the site to display the password on multiple lines for mobile.

I have bookmarked this site for my own personal use. I also shared it with my co-workers in the IT dept.

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!

Reminds me of the perl module `hsxkpasswd`[0] which has more configure options, and also powers the online generator at https://xkpasswd.net/s/

[0]: https://github.com/bbusschots/hsxkpasswd

For passwords I might have to enter by hand, such as WiFi passwords, I liked the pronounceable password option that 1Password used to have. The passwords were several single syllables string together by a separator. An example: neg-pen-nau-eng-fri-dot. There were options to change the separator, and to toss in digits and upper case if I remember correctly. Syllables were 2 to 4 letters long, I believe.

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

Me too. I actually built my "ideal" password generator because nothing else was really cutting it for me. And an online generator is a no go. Because of security, of course, but I also just want to pipe my password straight into my clipboard, for example.

https://github.com/pkulak/pgen

I rely on the built in password generator of Passfindr https://passfindr.com using the same random number generator as mentioned in correcthorse.pw. When using a Password Manager, and one should, different passwords for every internet account is straight forward.

You forgot the translate to Finnish step

You can achieve this with a one-liner:

shuf -n 4 /usr/share/dict/words

This is top comment material.

This reminds me of the infamous Dropbox comment: https://news.ycombinator.com/item?id=9224

... which is useless for your average non-technical user who wants to increase their password security but isn't comfortable with a terminal emulator.

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.

This may not be cryptographically secure. Shuf can default to using a small amount of entropy.[1,2,3] To be certain, you can add the --random-source option:

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.

I'm curious how practical an RNG attack actually is here (which absolutely isn't meant to serve as criticism of your surfacing the issue!).

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

Depends on the situation.

I definitely wouldn't try this on a freshly booted Raspberry Pi, for example.

shuf uses randint(), which defaults to /dev/urandom as the nonce source:

https://github.com/coreutils/coreutils/blob/v8.31/gl/lib/ran...

It's going to be as practical to attack as anything that uses /dev/urandom.

For sufficiently recent versions of shuf. It looks (... at a skim of the history, I could be confused) like older versions use pid, ppid, uid, gid, and time. In that case that's likely to be more practical than brute force if you've generated a password with notionally more than ~40 bits of entropy.

That said, I suspect most people are indeed on a platform with a sufficiently recent version of shuf.

(And a sufficiently old version may lack the random-source option.)

RHEL 6 will be EOLd this November. That's the last supported version of RHEL that has this issue. Ubuntu 13.04, RHEL 7 and later don't suffer from this issue.

I'd say almost everyone reading these comments is on a platform that does not suffer from this issue.

shuf uses randint(), which defaults to /dev/urandom as the nonce source:

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.

Interesting. They stopped using /dev/urandom as the default random file in version 7.3, which created the insecure default situation. Later, in version 8.6, they updated to use a default nonce from /dev/urandom. It's odd that the documentation has not be updated. Perhaps it's because the latest version will still default to an insecure nonce if there is no /dev/urandom?

If you're on a Linux OS that's from ~2013 or later, then you're most likely on a version of coreutils that will default to /dev/urandom.

The master branch of coreutils is using getrandom(2). It will continue to draw entropy from the urandom source by default.

The latest versions of RHEL/CentOS 6 use coreutils version 8.4, so I assume their shuf defaults to insecure. I imagine that RHEL 5 ELS must have the same issue. I don't know of any other currently-supported Linux or BSD versions that might be a problem.

RHEL 5 is from 2007, and is already past end of life (end of extended support is this November).

RHEL 6 is from 2009, and it's end of life is this November.

Both of those OS are not from 2013 or later. They may have minor versions that were released later, but minor versions typically don't make significant changes to core packages.

RHEL 7 (2014) and Ubuntu 13.04 both have coreutils 8.20 or newer.

RHEL 6 ELS will be supported until 2024.

My comments are not contradictory to your point about 2013. They are only meant to make people aware that there are supported OS versions in use that have this issue.

RHEL 6 is end of life (product retirement) this November. ELS indeed extends out till 2024, but that's after the product has been officially retired/EOLed.

Essentially, come November, there will not be a generally supported Linux OS that will have this issue.

You seem to be arguing that there will be no need to use the --random-source option after November. If so, that is incorrect in my view.

ELS versions receive critical security fixes and urgent bug fixes until the end of their support. They are used right up to end of support, or even beyond in some cases.

RHEL 5 ELS will be supported thru November 30, 2020 and RHEL 6 ELS will be supported thru June 30, 2024.

This implies there will be RHEL 5 ELS users for at least 5 more months and there will be RHEL 6 ELS users for at least 4 more years.

So, for at least four more years, it appears there will be users who should use the --random-source option with shuf if they want to be cryptographically secure.

>You seem to be arguing that there will be no need to use the --random-source option after November. If so, that is incorrect in my view.

The argument is that if you're on a currently supported, non-EOL Linux OS, you will not have this issue after November (since at that point in time, the RHEL 6 will be past end of life).

>ELS versions receive critical security fixes and urgent bug fixes until the end of their support. They are used right up to end of support, or even beyond in some cases, although that is certainly not recommended.

ELS versions are considered past EOL, and past Maintenance Support I & II. They will not be supported for new installs, will be out of compliance for PCI DSS, HIPPA, almost all third party vendor software, will not be certified on new hardware, etc. They are past their ten year lifecycle.

https://endoflife.software/operating-systems/linux/red-hat-e... https://access.redhat.com/support/policy/updates/errata/#Ext...

Of course the few people on RHEL 6 will have to use the additional --random-source option, but the amount of people that this affects is in the single percentage point, or less.

Nothing is stopping someone from spinning up RHEL 5 three years from now and running my original command.

My original statements and points stand true. You were originally wrong to think that shuf is cryptographically insecure. It's been cryptographically secure for quite a while now.

> The argument is that if you're on a currently supported, non-EOL Linux OS, you will not have this issue after November (since at that point in time, the RHEL 6 will be past end of life).

Limiting to only non-EOL and to only future timelines after November are your own chosen statement limitations, not mine.

My statement that the shuf default is insecure for certain versions is correct and I have provided specific examples. There may be other examples, but I only need one to establish truth.

End of life dates have no bearing on my statement. You seem to be trying to change my statement into something else so you can say it is incorrect.

You can narrow your own statements to only include versions and future timelines that you think are important, which is fine, but it doesn't help those who will still be using the affected versions for years to come. The ELS versions exist for a reason, which should be clear from the fact that Red Hat is a for-profit entity. There is a significant number of projects in areas such as industrial control, defense, and finance, that place a high value on stability and they want that extra timeline that extends far beyond end of life.

>Limiting to only non-EOL and to only future timelines after November are your own chosen statement limitations, not mine.

My statement was a Linux OS after 2013ish, which means RHEL 7 and Ubuntu 13.02. RHEL 6/5 are not from 2013 or later.

>My statement that the shuf default is insecure for certain versions is correct and I have provided specific examples. There may be other examples, but I only need one to establish truth.

There are certain default versions of the kernel, bash, etc. that are insecure for certain versions of Linux OS releases. Your statement is meaningless. You can go back in time and find an insecure version of a piece of software, that's almost always true, you established effectively nothing. Whether or not anyone is using that version is what's meaningful.

You might as well be warning people not to visit https://correcthorse.pw/ on the default Firefox that ships with RHEL 5 because it had insecure defaults.

>End of life dates have no bearing on my statement. You seem to be trying to change my statement into something else so you can say it is incorrect.

It does, as I stated and proved above. Everything you've said is pretty much incorrect, which is the problem.

>You can narrow your own statements to only include versions and future timelines that you think are important, which is fine, but it doesn't help those who will still be using the affected versions for years to come.

Effectively no one is going to use the impacted versions for years to come. I doubt there are any users reading this comment thread who use RHEL 6 for password generation.

>The ELS versions exist for a reason, which should be clear from the fact that Red Hat is a for-profit entity.

They exist for the same reason Windows will sell you support for Windows XP, even though that product is also EOL. Are you going to warn the .x% of users that are using Windows XP to not even connect to the Internet?

>There is a significant number of projects in areas such as industrial control, defense, and finance, that place a high value on stability and they want that extra timeline that extends far beyond end of life.

Finance definitely places a high value on being on supported versions. As a matter of fact, it's against PCI DSS to be on EOL products. They have entire audit and compliance teams to ensure they're not on EOL products.

> Are you going to warn the .x% of users that are using Windows XP to not even connect to the Internet?

Sure. The fact that more than 1% of Windows PCs still run XP suggests that additional warning is merited.

Please don't connect to the internet with Windows XP. It's not safe. Extended support ended in 2014.

serioludicrous simpleheartedness seminiferal phrenologize

no thanks.

For easier-to-remember passphrases, you can download the EFF wordlist from https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt and specify that file instead of /usr/share/dict/words

Thanks. I had no idea that shuf existed, cool. Another useful tool for my occasional command line work.

I don't think they'll appreciate you posting the source code to their application!

lower, upper and numbers = 62 options | wordlist = 10 000 options:

    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.

If I may egregiously misuse the famous quote, "those who do not understand Unix are condemned to reinvent it, poorly."

    $ shuf --random-source=/dev/urandom -n6 /usr/share/dict/cracklib-small | paste -sd-
    circulant-conjured-reigning-buzzed-awaiting-typifies

See also https://theworld.com/~reinhold/diceware.html (the "original", as far as I know).

KeePassXC 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!

I tend to rely on https://www.rempe.us/diceware/#eff for my typeable password needs.

80% of my passwords are just line noise, because they live in a keepass database. 20% (workstation account logins, etc) are diceware.

you type "glove blinks abruptly avatar salvaging marbled" every time you need to unlock your screen?

I don't know about GP, but I certainly do.

Mine's a more meaningful sentence, but about the same length, yes.

It doesn't take long to type a wholly-memorized sentence.

Based on the typically strict Corporate 5-minute auto-lock you find on work computers, that would get tiresome REALLY quickly :(

Honestly, it's not any worse than a more typical number and symbol stew. You'd be surprised how quickly you can type a 40 character sentence, especially one that you've developed a bit of muscle memory for. I think it's likely as fast, if not faster than the more "typical" 12-16 character special-symbol fest.

i type quickly.

Shout out to the open source Bitwarden project which includes this out of the box. Check out bitwarden_rs for a good sefhosted option.

I know XKCD made a comic and everything, but isn't this type of password exactly why dictionary attacks exist?

The whole point of the xkcd comic is that even if someone is using the same dictionary, the phrase has sufficient entropy to be secure.

In the original comic it is shown that entropy of these passwords is still higher than the method with random words and substitutions. That means more combinations even with full knowledge of used dictionary

They're not bad, if the password is long enough. So if you have 3 shorter words, add another word or two to increase it's length.

Reply on news.ycombinator.com