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

NIST’s new password rules – what you need to know

nakedsecurity.sophos.com

Post reply on HN
Print view View original

81–90 of 237 posts

Re: NIST’s new password rules – what you need to know

#81

Post by userbinator »

mschuster91 wrote: post #33

> and should accept all UNICODE characters, too, including emoji Hell no. This WILL lead to disaster, especially if people store their passwords in managers that may or may not mess up Unicode. UTF-8, for example, allows to encode the character "ä" as \xc3\xa4 OR \x61\xcc\x88. They look visually identical, yet fail any string comparison. Not to mention the support calls "I'm in $random_foreign_country and don't have…

Personally, I think passwords should be opaque sequences of bytes that just happen to be mostly easily input on a keyboard, but I agree with the warning: some might even consider such a warning a good thing.

Re: NIST’s new password rules – what you need to know

#82

Post by jrochkind1 »

> Applications must allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji!

Man, I predict a world of hurt here. Maybe it'll be okay if the standards also very prominently tell you you've got to unicode normalize before hashing, and tell you what normalization form to use (NFC I think?). Too many platforms/environments still don't have handy access to unicode normalization though.

Re: NIST’s new password rules – what you need to know

#83

Post by jrochkind1 »

riskable wrote: post #70

The importance of this NIST standard cannot be understated. It has a requirement that passwords be hashed with a random salt ! Microsoft Active Directory does not use salts ! I am trying to imagine the consequences to all the businesses and agencies that must adhere to these standards suddenly coming to the realization that they must replace their Active Directory installations and what that will mean for administeri…

Presumably Microsoft would add a salt before losing all that business. Perhaps only if you turn on special NIST-mode, in the way of microsoft and backwards compatibility.

It might break some functionality, but probably not as much as moving to an entirely different product if you have things written against MS APIs.

Re: NIST’s new password rules – what you need to know

#84

Post by mark-r »

mrmagooey wrote: post #54
mark-r wrote: post #50

Earlier quoted context omitted.

How do you know how many words are in the passphrase?

You don't I guess, I'm just using 4 as an example (it's also the number of words used in xkcd's password strength comic).

I only ask because a different answer will change the math drastically.

Re: NIST’s new password rules – what you need to know

#85

Post by TJSomething »

jrochkind1 wrote: post #82

> Applications must allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji! Man, I predict a world of hurt here. Maybe it'll be okay if the standards also very prominently tell you you've got to unicode normalize before hashing, and tell you what normalization form to use (NFC I think?). Too many platforms/environments still don't have handy access to un…

It actually does:

https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-sec...

Re: NIST’s new password rules – what you need to know

#86

Post by nerdy »

elchief wrote: post #73

Seeing as NIST recommends PBKDF2 over bcrypt and scrypt should we assume that means NSA can crack PBKDF2 faster / more cheaply?

This is the first thing I thought too. I've consistently heard the opposite but am not a cryptographer.

The article Sophos links with regards to an explanation for choosing PBKDF2 over bcrypt or scrypt goes over numerous obviously bad practices like cleartext storage, then states the following, without further detail:

We’ll recommend PBKDF2 here because it is based on hashing primitives that satisfy many national and international standards.

This seems like a vague and probably misguided line of reasoning. What specifically would make that recommendation rational? bcrypt wasn't new in 2010 when NIST published the article recommending PBKDF2, and they haven't made the switch since. Dual_EC_DRBG was recommended by NIST in 2006 which makes me deeply skeptical of anything they say.

If anyone could provide the motivation for choosing PBKDF2 in reasonably terms I'd appreciate it.

Re: NIST’s new password rules – what you need to know

#87

Post by ryanar »

I love this. I despise the fact that my bank restricts passwords lengths to max 16 chars, hash lengths are constant, it is ridiculous. It is a BANK, if anything they should be more secure.

Instead they force me to make passwords that easily fit a password mask by restricting special characters and forcing at least one number, uppercase letter, etc. They are actually weakening the security in a vain attempt to get people to make stronger passwords. All they do is make it P@$$w0rd instead, no increased security, it is so predictable

I think disallowing SMS for 2FA will make it harder to get people to use it, if they finally decide to signup then they are informed they need an authenticator program. Also there have been times my phone was dead and I didnt have a backup plan.

Re: NIST’s new password rules – what you need to know

#88

Post by koolba »

What's the only thing worse / stupider / more annoying than secret questions?

Secret questions that don't even have a free form text box for the answer! That means you can't even put random text in them. You have to select from a pre-canned list of 5-10 options.

Good riddance!

Re: NIST’s new password rules – what you need to know

#89

Post by macintux »

freehunter wrote: post #38
GordonS wrote: post #30

Earlier quoted context omitted.

I've had this before with my bank, when I've had to authorise a large card payment (for a car). I was asked various security questions about monthly recurring payments from my account (in the UK, so standing orders and direct debits), but I've so many I can't keep up, and I change savings accounts and health, car, home, pet insurer every year to get a good deal. The rep on the phone kept prompting me when I was unsur…

I had the opposite recently. Trying to log into my alma mater's website to get a copy of transcripts, but my account had long ago locked out. They asked me questions over the phone to reset it, but I couldn't answer any of them. "What is your phone number on file?" Shoot, I don't know, it was an old number that I changed maybe 6 years ago... "What is your address on file?" I've moved maybe five times since then? I tr…

I've found that the only known repository of all my previous addresses is Amazon. I really need to capture them to 1Password.

Re: NIST’s new password rules – what you need to know

#90

Post by dannysu »

mrmagooey wrote: post #43

Aren't passphrases kind of a bad choice for passwords? If all you are ever really guessing is the symbols that make up someones password, and you know that for example they have 4 words that make the passphrase, then you effectively only have to iterate 4 symbols with a known list of possibilities for each symbol (i.e. the dictionary). If you compare the permutation space of a short passwords (length 7) with random c…

What we should really talk about is the password entropy like what you've done.

If you take the xkcdpass package from Ubuntu, it uses a word list of 41230 words by default [1]. That's 41230^4 and about 61-bit of password entropy. If you want to use a smaller word list, add words to the passphrase until you reach a desirable password entropy.

Using your example of 80^7 for random characters, that's only 44-bit password entropy. So in this case, xkcdpass gives you a stronger password with just 4 words. If you want to reduce the word list to 3000, just add 1 more word and it's 46-bit password entropy. A decision between 7 random characters vs 5 words.

I personally prefer random characters because you can up the entropy significantly, and I have no problem remembering random sequence in the mid-teens range. That can easily get you 90-bit entropy or more. Everything else is saved in my password manager and there you can up the entropy even more. My auto-generated passwords are usually around 200-bit entropy.

  [1]: https://github.com/redacted/XKCD-password-generator
Post reply on HN