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

221–230 of 237 posts

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

#221

Post by ghshephard »

peeters wrote: post #214
rikkus wrote: 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.

I think in the real world there are two scenarios, someone is using one of PBKDF2/Bcrypt/Scrypt - in which case all of this is moot, set an appropriate work factor/#of iterations, and you are secure with even a moderate sanity check against the password. Interesting note - said sanity check, ironically, could be a simple as a lookup - the top 4 billion passwords can be stored in a packed 24 gigabyte lookup table on disk which can be searched in The other scenario is when you doing a single pass of a hash, in which case the salt is irrelevant for the security of that password.

Everyone here understands that you need to salt when your dictionary takes a long time to build (Say, more than 1 millisecond/password, which equals 2.5 billion passwords/month) - not everyone appreciates that salting a fast password (more than 2.5 billion passwords/second) - adds no security to that particular password.

The scenario where there is moderate "stretching" (by which I presume you mean running multiple iterations of a hash), with no randomized salt, is a bit of a straw man - who would bother to go the effort of "stretching" and not stick a randomized salt in while they are at it?

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

#222

Post by tomjen3 »

oneeyedpigeon wrote: post #165
sbuttgereit wrote: post #109

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!

When that happens, turn up the work factor on the hash.

And 64 is a pretty low limit if you want to use a passphrase.

"He who fights monsters will have to look into fighting scammers too" is both a decently difficult password to guess, pretty easy to remember and too long.

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

#223

Post by riskable »

euroclydon wrote: post #202
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…

Can NTLM, which prevents sending the password itself across the network, work with random salts?

No it cannot since the authenticating client won't know the salt.

NTLM isn't the only authentication method that is fundamentally incompatible with salts. The way Windows clients perform initial Kerberos authentication (getting the TGT) will break as well.

Kerberos is easier to fix though since the protocol was made to work with salts. It's just that the way Microsoft implemented it leaves it vulnerable to pass-the-hash styled attacks.

Another issue is how applications handle incoming Kerberos authentication. For example, when you configure IIS to perform Kerberos authentication you (usually) need to specify a service account and provide the password. Instead of storing the password IIS will simply pre-compute the hash (which it can do because there's no random salt) and store the result using DPAPI (I think... Since it's a Microsoft product it may use a different nonpublic API). If using random salts IIS won't be able to do that anymore and will have to work like traditional MIT Kerberos applications--using a keytab (provided by an administrator).

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

#224

Post by koolba »

jandrese wrote: post #217
estefan wrote: post #172

Earlier quoted context omitted.

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?"

"What is your opinion of cargo cult infosec practices, specifically security questions?"

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

#225

Post by lenocinor »

jandrese wrote: post #217
estefan wrote: post #172

Earlier quoted context omitted.

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?"

Going to guess they wrote it themselves in this case.

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

#226

Post by monkeywork »

cdubzzz wrote: post #185
monkeywork wrote: post #147

Earlier quoted context omitted.

again if your corp doesn't have a policy for off-boarding employees and removing their access then you've failed. If your corp doesn't have a policy of not having shared accounts then you've failed... if you are forced to have shared accounts then you need to have in your off-boarding policy that anyone who had access (which was a purely need to know basis) once off-boarded would trigger that password change. The poi…

I agree with you in principal, but is also important to remember that policy != practice. For a policy against shared accounts, for example, there is no reasonable way to guarantee that Employee A has not given his password to Fired Employee B.

if you are compromised in that manner "Employee A has not given his password to Fired Employee B." then no password policy is going to save you.

Also remember passwords are only ONE part of your security armour, they aren't the entire suit.

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

#227

Post by colanderman »

nmjenkins wrote: post #80
colanderman wrote: post #28

Earlier quoted context omitted.

Yep. FastMail restricts spaces in passwords due to mail clients that do not allow them.

(FastMail developer here) The issue was actually that we support many different protocols (not just mail) and some combinations of clients/protocols have had issues in the past (it might have been some FTP clients I think, but can't remember right now.) Anyway, this restriction no longer applies as we now require server-generated app passwords for 3rd party apps: https://www.fastmail.com/help/clients/apppassword.html…

I didn't know that, thanks, and thanks for providing a product I can rely on!

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

#228

Post by paulddraper »

kisstheblade wrote: post #219
kevhito wrote: post #200

Earlier quoted context omitted.

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.

Better that then 81Pk3t?Rq6S}

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

#229

Post by platz »

monkeywork wrote: post #226
cdubzzz wrote: post #185

Earlier quoted context omitted.

I agree with you in principal, but is also important to remember that policy != practice. For a policy against shared accounts, for example, there is no reasonable way to guarantee that Employee A has not given his password to Fired Employee B.

if you are compromised in that manner "Employee A has not given his password to Fired Employee B." then no password policy is going to save you. Also remember passwords are only ONE part of your security armour, they aren't the entire suit.

http://i.imgur.com/kU3jB9B.jpg

http://i.imgur.com/OeIRC5U.jpg

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

#230

Post by zeroer »

dfox wrote: post #155
ma2rten wrote: post #116

Earlier quoted context omitted.

Not half as bad as Social Security Numbers.

SSNs are identifiers and when knowledge of SSN gets you some privileges, it's problem with whatever gives you these privileges. Card numbers are on the other hand essentially explicitly designed to be used as authentication data and at the same time printed in big letters on the card and known by all parties involved in transaction.

They're both pretty bad.
Post reply on HN