NIST’s new password rules – what you need to know • Hacker News Board

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

#171

Post by mjevans » Wed, Nov 23, 2016, 10:27 AM UTC

hvidgaard wrote: post #146

whiteandnerdy wrote: post #138

Earlier quoted context omitted.

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…

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.

You can if it's a computer picking the password from presumably common words.

If the human is picking anything than there WILL be a bias in selection. Effort should be made at minimizing that, but even with education this is a difficult task for any worker.

It got to the point where I actually took a classic literary work and made a 'password words' dictionary from it just so that I could have the computer generate possible new passwords. (there bias is mostly filtering out things that might be offensive... because someone can always take it the wrong way even if you explain in advance the theory of how the password was created by a computer).

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

#172

Post by estefan » Wed, Nov 23, 2016, 11:10 AM UTC

OptimalRoasted wrote: post #97

koolba wrote: post #91

Earlier quoted context omitted.

Here's what I use to generate answers to secret questions: This leads to things like: > "What is your first pet's name?" "q1ry9nftmxb1gmag" I haven't had it happen yet, but I wonder what a customer service rep's response will be when I spell out "yrlmduihhyju5il0" when asked what my favorite color is.

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

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

#173

Post by sbuttgereit » Wed, Nov 23, 2016, 11:10 AM UTC

flukus wrote: post #121

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.

But what if I want the complete contents of war and peace to be my password?

  You can't always get what you want
  But if you try sometimes well you might find
  You get what you need

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

#174

Post by rikkus » Wed, Nov 23, 2016, 11:10 AM UTC

peeters wrote: post #104

ghshephard wrote: post #93

Earlier quoted context omitted.

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. 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;

  foreach (var password in File.ReadLines(@"c:\temp\10_million_password_list_top_1000000.txt"))
  {
    System.Security.Cryptography.SHA256.Create().ComputeHash(Encoding.UTF8.GetBytes(password + salt));
    ++crackCount;
  }

  stopwatch.Elapsed.Dump();
  crackCount.Dump();

=>

  00:00:02.0981333
  999999

Salt is indeed important, but the only real way to protect is to iterate - PBKDF2/scrypt/bcrypt.

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

#175

Post by chris_wot » Wed, Nov 23, 2016, 11:21 AM UTC

TorKlingberg wrote: post #168

Freak_NL wrote: post #154

Earlier quoted context omitted.

Yes, my mother's maiden name is Een3oquu+P_a9oez0queiPhaeChaijoh, why do you ask? Ironically, you usually can enter a string as answer to those questions that is more secure than the allowed password.

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

Amazing how we don't allow support to know the password, but the security question answers that allow access - that' fine!

If I had to break in to an account, I'd choose one that used recovery questions. That'S far easier than cracking a password.

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

#176

Post by chris_wot » Wed, Nov 23, 2016, 11:22 AM UTC

cmsmith wrote: post #103

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.

3M has made a lot of money out of these companies.

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

#177

Post by chris_wot » Wed, Nov 23, 2016, 11:26 AM UTC

sib wrote: post #9

adrr wrote: post #4

Earlier quoted context omitted.

PCI compliance requires quarterly rotation of passwords and keys.

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

My passwords are always surprised or overly enthusiastic. MyPassword123! Soon becomes MyPassword123!! And then as I progress in the company my enthusiasm gets even more hyper MyPassword!!!!!

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

#178

Post by shthed » Wed, Nov 23, 2016, 11:27 AM UTC

Also systems should always notify users if their password or email address has been changed, immediately alerting that they've been compromised.

2factor authentication is great so you always know if someone is attempting to login as you.

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

#179

Post by hollander » Wed, Nov 23, 2016, 11:37 AM UTC

hvidgaard wrote: post #146

whiteandnerdy wrote: post #138

Earlier quoted context omitted.

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…

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.

Mix in some other languages or slang words, and a number is always possible and easy to remember. You may choose to replace the space consequently with a comma or ; or another easy to type character (not one that requires a shift if you keep everything lowercase).

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

#180

Post by hollander » Wed, Nov 23, 2016, 11:53 AM UTC

cmsmith wrote: post #103

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.

So did you use a written note in your wallet or a password manager on your smartphone (from which you can read it)? What did you or the average colleague do?