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

151–160 of 237 posts

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

#151

Post by oneeyedpigeon »

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.

None of [ "correct", "horse", "battery", "staple" ] are in that 100 list, though.

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

#152

Post by Biganon »

kevhito wrote: post #52
mrmagooey wrote: post #43

Aren't passphrases kind of a bad choice for passwords? If all you are ever really guessing is the symbols that make up someones password, and you know that for example they have 4 words that make the passphrase, then you effectively only have to iterate 4 symbols with a known list of possibilities for each symbol (i.e. the dictionary). If you compare the permutation space of a short passwords (length 7) with random c…

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?

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

#153

Post by Qantourisc »

kbart wrote: post #135
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?

The same way to index websites: with web-spiders. They would need to write new code for this though. Also for HTTPS they also had to write new code.

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

#154

Post by Freak_NL »

brownbat wrote: post #133

> 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. Almo…

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.

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

#155

Post by dfox »

ma2rten wrote: post #116
zeroer wrote: post #110

Earlier quoted context omitted.

Credit card numbers themselves are security theater.

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.

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

#156

Post by Symbiote »

hvidgaard wrote: post #148
jejeuhds wrote: post #141

Earlier quoted context omitted.

No, you are wrong. The number of bits of entropy in "horsestaple..." is estimated by assuming the words where chosen at random from the 2^11=2048 most common words. 4*11=44 bits in total. In practice it is even better since a hacker would also try different kinds of passwords! So no, you do not need substitute characters.

Yes, I was wrong about the entropy when writing that. But I still don't think that passphrases are as godsend as the comic make it seem. Can we really assume 2048 common words? The 100 most commonly used, make up 50% of written words. A common sentence like "I drove to the mall yesterday" is not a good passphrase, but I'm certain that people who use "rocket" as a password would do something similar.

The intention is that the random words are selected from a list of 2000 unique, common words.

Choosing a sentence is a different strategy, which is less secure.

    $ wget -O ⅓Mwords http://norvig.com/ngrams/count_1w.txt
    $ for i in `seq 10`; awk '/^[a-z]{3,}/ { print $1 }' ⅓Mwords | head -n 2000 | shuf -n 5 | tr '\n' ' ' && echo
    videos possible disease maintenance chair 
    teen documents than without son 
    research interface library largest drive 
    location ball beauty coming files 
    files middle fri meet air 
    guarantee samsung click super inn 
    legal previous rent resort use 
    reply thought better fresh phentermine 
    bad command once vehicle australian 
    fun random professor course sponsored

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

#157

Post by oneeyedpigeon »

kbart wrote: post #135
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?

Couldn't Google just auto-register an account with a known good password, and penalise the account if it fails? Someone else mentioned improving the http authentication 'api', which would definitely help in this regard; until then there are drawbacks to the auto-register approach including things like captchas. Sites would have to explicitly allow the Google bot to bypass them.

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

#158

Post by hvidgaard »

Symbiote wrote: post #156
hvidgaard wrote: post #148

Earlier quoted context omitted.

Yes, I was wrong about the entropy when writing that. But I still don't think that passphrases are as godsend as the comic make it seem. Can we really assume 2048 common words? The 100 most commonly used, make up 50% of written words. A common sentence like "I drove to the mall yesterday" is not a good passphrase, but I'm certain that people who use "rocket" as a password would do something similar.

The intention is that the random words are selected from a list of 2000 unique, common words. Choosing a sentence is a different strategy, which is less secure. $ wget -O ⅓Mwords http://norvig.com/ngrams/count_1w.txt $ for i in `seq 10`; awk '/^[a-z]{3,}/ { print $1 }' ⅓Mwords | head -n 2000 | shuf -n 5 | tr '\n' ' ' && echo videos possible disease maintenance chair teen documents than without son research interface…

A random 5 words is hardly simple or easy to remember. The entire selling point of passphrases is exactly that.

It's a hard problem that is IMO best solved with hardware secure keeping of secrets and a rate limited pincode.

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

#159

Post by oneeyedpigeon »

callmeal wrote: post #102
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.

Apparently, sexually explicit concepts (maybe all 'shocking' concepts?) are very highly memorable, so that's probably a good approach!

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

#160

Post by esseti »

Question: how do you store data encryption key for each user?

because:

- you get the password form the user

- compute the PBKDF2 with iteration and a salt, store iteration$salt$hash (where hash is the result of the PBKDF2 on the password).

- when user logs in check that the hash matches the PBKDF2 on password with iteration and salt.

But now, i've a the data enccryption key (DEK) and i've to store it somewhere. I can't use the password directly to encrypt the DEK since the lenght must be 32 (or 16, or 24). I should use PBKDF2 to derive a 32 byte hash, but this value is already stored in the password_hashed field. Should I compute anoterh PBKDF2 with a different salt and a different iterations for the encryption of DEK? if so i'll store in the db just$iterations and encryption and apply those to the password (after the user logs in) to derive an encryption key for the DEK?

What's a good approach?

Post reply on HN