Live data from Hacker News

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

nakedsecurity.sophos.com

211–220 of 237 posts

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

#211
post #52

Earlier quoted context omitted.

Everything in the article is spot on, I only wish they went further and recommended passphrases more strongly. It's correct horse battery staple and all that. As for your calculation, you are about right. Except memorizing a completely random 8 character password drawn from an 80 symbol alphabet is /extremely/ unpleasant for most people, especially when you may have a few different passwords you use on a daily or wee…

So you have memorized the equivalent of a 60-word nonsensical poem?

Well, you only need to memorize the passphrase of your password manager's file.

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

#212
post #84

Earlier quoted context omitted.

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.

No it doesn't. Your password has as much entropy as it has, and no more.

If you want to follow that train of thought to its logical conclusion, your attacker not only doesn't know the length of the password, they don't know what character sets make up the password either, and so you could claim that a 4-character numeric password is equally secure to a 64-character Unicode password. In fact by inductive reasoning 4-digit password could be said to have pretty much any finite amount of entropy, because how does the attacker know that it's not actually length N+1?

Yes, the attacker not knowing exactly what the password class is (words/character set/length) does help somewhat in a practical sense. But it doesn't "change the math" at all, if you have 3000 symbols (words) and your password is 4 of them then you have 3000^4 possible passwords. You don't get to count passwords that are not in your password class as part of your entropy.

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

#213
post #212
post #84

Earlier quoted context omitted.

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

No it doesn't. Your password has as much entropy as it has, and no more. If you want to follow that train of thought to its logical conclusion, your attacker not only doesn't know the length of the password, they don't know what character sets make up the password either, and so you could claim that a 4-character numeric password is equally secure to a 64-character Unicode password. In fact by inductive reasoning 4-d…

I didn't mean math in general, I meant the math used in the post I was responding to, which had some unfounded assumptions. I can make assumptions too with vastly different outcomes, I'm sure that 10 random unrelated words are more secure than 10 random unrelated characters.

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

#214
post #174

Earlier quoted context omitted.

Even if you assume weak passwords, there's no comparison in effort when you involve stretching. No salt means you can precompute the hash for the 1,000,000 most common passwords. That'll take maybe an hour or two with aggressive stretching. Then you check it against the million or so records in the database for any matches. Salt means FOR EACH RECORD in the database, you have to compute those 1,000,000 passwords. Tha…

> Salt means FOR EACH RECORD in the database, you have to compute those 1,000,000 passwords. That means you're talking about decades of computation time. SHA256 of the million most common passwords (with a 128 bit salt) takes 2 seconds /total/ on my laptop. That's only 42 days required to crack a database of one million hashes. var stopwatch = Stopwatch.StartNew(); var salt = "0123456789012345"; int crackCount = 0; f…

Are you ignoring the part where I said "when you involve stretching?"

The claim was that salting is irrelevant compared to stretching. It is not. It is still unbelievably important even when doing stretching.

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

#215
post #186

Earlier quoted context omitted.

And then you call phone support and they ask you for it.

"I just entered a string of random characters." "That is correct. Thank you."

mentally: "I knew he was the kind of guy who would do that."

"Go ahead and transfer all of the billing information to this address and change the email to evilhacker@guy.com. Thanks."

CSR: "Sure, I'm happy to be of help."

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

#216
post #21

Earlier quoted context omitted.

That's true, but I'm having hard time thinking of a use case where a sustained, hidden compromise is 'worse' than a one-time compromise. I mean, I guess they could login to your bank every week and transfer out $50 instead of just transferring out all your money on day 1, but... ?

There are quite a few scenarios where a sustained, hidden compromise is an (or several) order of magnitude worse than a one time obvious compromise. The first to come to mind is a corporate espionage scenario. Do you want to know what your competitor is up to today, or do you want access to their briefings/CAD/code for the next 12 months? Long duration compromises also allow you to slip data out slowly, so a NAS does…

An APT isn't going to log in with the password every time. They're going to install a rootkit.

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

#217

Earlier quoted context omitted.

The guy on the phone laughed. I've moved to providing a few random words, easier to say over the phone than capital y lowercase r number 1.... etc.

The woman on the phone at the utility company that was messing me around didn't laugh when I said the answer to my security question "what do you think of customer service" was "f*cking retards" :-D

Who even makes that a security question? I mean seriously. You might as well ask "What is your opinion on the color yellow?"

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

#218

Earlier quoted context omitted.

For which they set a 4K limit on password length. I think even the commenter you replied to would find that satisfactory, being much more than 64 characters.

It's pretty arbitrary when you get to 64, IMO. If a site enforces a maximum below that, I'll feel suspicious and treat the site as if it's storing my password in plain text; that maximum or higher reassures me that they probably know what they're doing. Of course, one day, a 64-character password will be brute-forceable in milliseconds, but we hopefully won't still be having this discussion by then!

64 lowercase English letters is 10^92 bits of entropy, which is around the same number of atoms in the universe. Eventually the laws of physics put an upper bound on how much entropy you need to avoid brute force attacks.

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

#219

Earlier quoted context omitted.

Can we really assume 2048 different words? 100 words make up 50% of all words written according to this https://en.wikipedia.org/wiki/Most_common_words_in_English ? I was a bit hasty of the entropy of the passphrase, my mistake. I still stand by that even if we choose from 2048 common words, generating a good passphrase (one that isn't a common sentence) is harder than we think.

Yes, 2048 is tiny. I've been using a 4096-word dictionary I found online for years, along with my family and two kids since they were about 6 years old. There is absolutely no trouble with a 4096 word dictionary. Yes, they (and me too) sometimes bump into words we don't recognize, but it's not that common. Here, I just generated you a few passwords: * hefty march attempt force bowel scuff * between sepia book sweat l…

Yes and good luck writing those passwords like "between sepia book sweat lemma saint" without typos :)

I just watched a friend using some kind of long password and it took about a minute to get the password correctly entered. Easy to look at the keyboard also when he was typing and guess the words used.

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

#220
post #174

Earlier quoted context omitted.

> Salt means FOR EACH RECORD in the database, you have to compute those 1,000,000 passwords. That means you're talking about decades of computation time. SHA256 of the million most common passwords (with a 128 bit salt) takes 2 seconds /total/ on my laptop. That's only 42 days required to crack a database of one million hashes. var stopwatch = Stopwatch.StartNew(); var salt = "0123456789012345"; int crackCount = 0; f…

Are you ignoring the part where I said "when you involve stretching?" The claim was that salting is irrelevant compared to stretching. It is not. It is still unbelievably important even when doing stretching.

Sorry yes I obviously missed that bit.
Post reply on HN