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

131–140 of 237 posts

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

#131

Post by tjbiddle »

freehunter wrote: post #46
niftich wrote: post #26

Earlier quoted context omitted.

Many [1]. Some examples, my comments in parentheses: - Out-of-Band Authenticators (mobile app over secure channel) - Single Factor OTP Device (like an OATH push-button, enter 6-digit code TOTP device) - Single Factor Cryptographic Devices (insert into computer) (among others) [1] https://pages.nist.gov/800-63-3/sp800-63b.html#sec5

Which is a real shame. SMS might not be perfect, but it's a real help when I don't have a better means handy. Its better than no 2FA, and it's saved my butt a few times when I get a text message saying "Here is your login code" and I'm out walking in the park. I get a new phone every year, and Google Authenticator sucks for that, but it's by far the second most common 2FA provider. I just got a new phone today, and h…

I use Authy - it's been a life-saver for having various phones get: Replaced, broken, reset, flashed during dev, etc.

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

#132

Post by hvidgaard »

tracker1 wrote: post #113
ams6110 wrote: post #107

Earlier quoted context omitted.

The problem is they are basically saying that almost every "best pratice" recommended over the past 5-10 years is absolutely the wrong thing to be doing. Don't be surprised when people throw up their hands in frustration.

It's been longer than 10 years, and known for quite some time by most.. The xkcd article is over 5yo itself, and a lot of people pushed for more open passwords for ages... I do one controversial think and that's trim password imput (mainly because of trailing whitespace selection in some apps/oses). Other than that, if you can input it, you can use it... though now doing some unicode normalization for unity combos is…

That comic is unfortunately not telling the truth. The password phrase IS 44 bits of entropy, assuming you input random ascii. But any reasonably knowledgeable person trying to crack passwords, will use a dictionary to create a passphrases, rendering this less useful than the first password. Even if you do substitute o/0/ø, i/l/1, a/4, ect randomly. You still need a rather long sentence, and preferably spice it up with simple substitution - now this passphrase is no longer easy or simple to remember.

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

#133

Post by brownbat »

> Knowledge-based authentication (KBA) is out.

All the rules are great, but this one might be my favorite. Every time I faced a list of KBAs I felt like I was trapped in UCB's comedy sketch:

https://www.youtube.com/watch?v=tMEjpXJZgIA

(If a common security device is bad enough for a comedy troupe to have a bit on it, maybe it could use some work.)

The worst KBAs I've seen are for United's frequent flyer program. Almost every question is of the form "What is your favorite X?" X includes items like "vegetable" or "summer sport." Maybe most people have strong opinions about the superiority of broccoli and tubing, but I was always just scratching my head. (The questions were mandatory and you could not write your own.)

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

#134

Post by mightybyte »

> Knowledge-based authentication (KBA) is out

Finally! This is my biggest beef. I've taken to generating long random strings as answers to these questions but in some cases that's insecure too because they present you with a multiple choice set of answers and then it's obvious.

Also glad they're getting rid of ridiculous composition rules, hints, and password expiration.

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

#135

Post by kbart »

mylesm wrote: post #7

Looks like some good suggestions: - Glad they're recommending a stop to the pointless "password must be no longer than (16, 20, ...) characters". Aren't you storing a constant-length hash anyway? - Why do some logins restrict which ASCII characters can be used? When I see that I can use any symbol from '%!#&' or whatever list they provide, I can only imagine it's a really naive SQL-injection defense. Is there any val…

" I know Google is planning on dinging sites that don't use HTTPS, is it possible they could ding sites for poor password policies?"

How they gonna do that? Do you expect Google to audit every site in their search ranks?

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

#136

Post by dotancohen »

bleachedsleet wrote: post #98
bsilvereagle wrote: post #45

Earlier quoted context omitted.

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…

Anecdotal and only related to your last paragraph, but as a security researcher I can say that 99% of the time attacks on a personal bank account are never "long term." Most of time, regardless of skill, hackers get in, cash out and disappear. It's far more lucrative (and generally safer) to empty the account than try to blackmail someone based on spending habits.

I happen to know of a bank exploit in which the attackers compromised one thousand online accounts, and attacked all them (transferring funds) on the same day.

Presumably the attackers were worried that after several transfers the bank would notice and block further access, so they kept a roster of compromised accounts to attack all at once. I suppose that a password rotation policy would have helped mitigate damage in this case, though something like fail2ban or automated IDS would have been better.

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

#137

Post by noja »

hvidgaard wrote: post #132
tracker1 wrote: post #113

Earlier quoted context omitted.

It's been longer than 10 years, and known for quite some time by most.. The xkcd article is over 5yo itself, and a lot of people pushed for more open passwords for ages... I do one controversial think and that's trim password imput (mainly because of trailing whitespace selection in some apps/oses). Other than that, if you can input it, you can use it... though now doing some unicode normalization for unity combos is…

That comic is unfortunately not telling the truth. The password phrase IS 44 bits of entropy, assuming you input random ascii. But any reasonably knowledgeable person trying to crack passwords, will use a dictionary to create a passphrases, rendering this less useful than the first password. Even if you do substitute o/0/ø, i/l/1, a/4, ect randomly. You still need a rather long sentence, and preferably spice it up wi…

Then why doesn't he update it?

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

#138

Post by whiteandnerdy »

hvidgaard wrote: post #132
tracker1 wrote: post #113

Earlier quoted context omitted.

It's been longer than 10 years, and known for quite some time by most.. The xkcd article is over 5yo itself, and a lot of people pushed for more open passwords for ages... I do one controversial think and that's trim password imput (mainly because of trailing whitespace selection in some apps/oses). Other than that, if you can input it, you can use it... though now doing some unicode normalization for unity combos is…

That comic is unfortunately not telling the truth. The password phrase IS 44 bits of entropy, assuming you input random ascii. But any reasonably knowledgeable person trying to crack passwords, will use a dictionary to create a passphrases, rendering this less useful than the first password. Even if you do substitute o/0/ø, i/l/1, a/4, ect randomly. You still need a rather long sentence, and preferably spice it up wi…

I think XKCD is correct here.

If you choose four random words from a list of 2048 common words, and your attacker knows that's what you're doing, then your entropy is 4 * log_2(2048) = 44 bits. If the attacker didn't know your strategy and tried to brute force letter by letter it would be much higher - around 48log_2(26)=150 bits assuming around eight letters per word - but like you said, we should assume the attacker knows exactly what strategy we're using, so 44 bits is the better number to work with.

Since that's still more than 28 bits, a 'correct horse battery staple' type password is harder to crack then a short random string of mixed characters, even if the attacker knows exactly what your password generation strategy is.

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

#139

Post by whiteandnerdy »

whiteandnerdy wrote: post #138
hvidgaard wrote: post #132

Earlier quoted context omitted.

That comic is unfortunately not telling the truth. The password phrase IS 44 bits of entropy, assuming you input random ascii. But any reasonably knowledgeable person trying to crack passwords, will use a dictionary to create a passphrases, rendering this less useful than the first password. Even if you do substitute o/0/ø, i/l/1, a/4, ect randomly. You still need a rather long sentence, and preferably spice it up wi…

I think XKCD is correct here. If you choose four random words from a list of 2048 common words, and your attacker knows that's what you're doing, then your entropy is 4 * log_2(2048) = 44 bits. If the attacker didn't know your strategy and tried to brute force letter by letter it would be much higher - around 4 8 log_2(26)=150 bits assuming around eight letters per word - but like you said, we should assume the attac…

> I think XKCD is correct here.

> If you choose four random words from a list of 2048 common words, and your attacker knows that's what you're doing, then your entropy is 4 * log_2(2048) = 44 bits. If the attacker didn't know your strategy and tried to brute force letter by letter it would be much higher - around 48log_2(26)=150 bits assuming around eight letters per word - but like you said, we should assume the attacker knows exactly what strategy we're using, so 44 bits is the better number to work with.

> Since that's still more than 28 bits, a 'correct horse battery staple' type password is harder to crack then a short random string of mixed characters, even if the attacker knows exactly what your password generation strategy is.

Typo in the above but can't edit on my phone, the second sum should be 4 \* 8 \* log_2(26). Apologies.

Post reply on HN