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

101–110 of 237 posts

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

#101

Post by grangerg »

nerdy wrote: post #86
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…

The best motivation I've heard is here: http://security.stackexchange.com/a/17088/77002

Essentially, blowfish (Bcrypt) doesn't appear to be FIPS-compliant, so if you have to be FIPS-compliant, you use PBKDF2.

And, considering the rest of the comments about why Bcrypt is preferred over PBKDF2, it appears it's all about how a GPU gives a significant speed-up for PBKDF2 but not Bcrypt. But now there are FPGAs that significantly speed up Bcrypt in similar fashion, so it could all be a wash depending on who you talk to.

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

#102

Post by callmeal »

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 usually have fun with security challenges. And get annoyed at ones with multiple choice answers.

What's your favorite movie? -> a sexual position

Where did you go to high school? -> another sexual position

City of birth? -> something else from the kamasutra

Of course, that makes phone conversations where they ask you those security questions very fun.

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

#103

Post by cmsmith »

lucaspiller wrote: post #3

Recommending not expiring based on time is probably my favourite. I've worked at two places where that's been a requirement and my password has always been a passphrase combined with a sequencial number.

I worked at NIST until recently, and my password expired every 90 days. We also had separate passwords for a half-dozen legacy IT systems (timesheets, travel requests, IT support, etc), all with more stringent and senseless length/character requirements than the last. And password managers were not allowed per security policy.

It was frustrating.

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

#104

Post by peeters »

ghshephard wrote: post #93
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…

If a salt matters, that means you can look it up in a dictionary of hashed passwords. Which means its in a very small search space. Which means a exhaustion search would find it quickly anyways. Far more relevant than "salts" would be using a PBKDF (See PBKDF2, SCRYPT, BCRYPT - which come with a salt for free anyways) with an appropriate number of iterations. What was the last year that Rainbow Tables were relevant a…

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. That means you're talking about decades of computation time. That's a heck of a lot more expensive. And importantly, you have to start that computation AFTER the breach, because that's when you gain access to the salts.

Salts are not unimportant.

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

#106

Post by platz »

bsilvereagle wrote: post #45
rconti wrote: 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…

The rotation guidance is partly to address employees who've left the company, vs generalized password cracking attempts.

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

#107

Post by ams6110 »

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…

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.

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

#108

Post by ams6110 »

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…

> 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 valid reason for this?

One reason I've seen for this is that the website is just a front-end for some older mainframe system that has password rules from 1987. Banks and insurance companies are frequently culprits here.

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

#109

Post by sbuttgereit »

elchief wrote: post #72
ipunchghosts wrote: post #40

How the f@@@ on the year 2016 we have a 64 character max length password requirement!!

If you allow unlimited length, that a DoS attack. Ask the devs at Django

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.

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

#110

Post by zeroer »

syshum wrote: post #39
sib wrote: post #9

Earlier quoted context omitted.

Nothing better than rules based on bad data and security theater.

That is the entirety of PCI PCI is nothing more than Security Theater so Mastercard and visa can claim it is all the merchants fault for data breaches and shield them from any liability

Credit card numbers themselves are security theater.
Post reply on HN