Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Correct Horse Battery Staple password generator

correcthorse.pw

Post reply on HN
Print view View original

81–90 of 99 posts

Re: Show HN: Correct Horse Battery Staple password generator

#81

Post by tomlagier »

Jaruzel wrote: post #65
tomlagier wrote: post #47

Earlier quoted context omitted.

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.

Re: Show HN: Correct Horse Battery Staple password generator

#82

Post by CPLX »

daveoc64 wrote: post #63
CPLX wrote: post #31

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.

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

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.

Re: Show HN: Correct Horse Battery Staple password generator

#83

Post by atoponce »

quantum5 wrote: post #78
atoponce wrote: post #71

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 resourc…

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 se…

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.

Re: Show HN: Correct Horse Battery Staple password generator

#84

Post by 1e-9 »

ThA0x2 wrote: post #79
1e-9 wrote: post #77

Earlier quoted context omitted.

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 imp…

>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 suppo…

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

Re: Show HN: Correct Horse Battery Staple password generator

#85

Post by 1e-9 »

perl4ever wrote: post #8
quantum5 wrote: post #2

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…

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

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.

Re: Show HN: Correct Horse Battery Staple password generator

#86

Post by ThA0x2 »

1e-9 wrote: post #84
ThA0x2 wrote: post #79

Earlier quoted context omitted.

>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 suppo…

> 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 e…

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

Re: Show HN: Correct Horse Battery Staple password generator

#87

Post by mlyle »

mlaci wrote: post #56

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.

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.

Re: Show HN: Correct Horse Battery Staple password generator

#88

Post by mlyle »

asdkhadsj wrote: post #69
daveoc64 wrote: post #61

Earlier quoted context omitted.

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 o…

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.

Re: Show HN: Correct Horse Battery Staple password generator

#89

Post by 1e-9 »

ThA0x2 wrote: post #86
1e-9 wrote: post #84

Earlier quoted context omitted.

> 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 e…

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

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

Re: Show HN: Correct Horse Battery Staple password generator

#90

Post by perl4ever »

quantum5 wrote: post #30
perl4ever wrote: post #8

Earlier quoted context omitted.

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.

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