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

91–100 of 237 posts

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

#91

Post by koolba »

1_2__3 wrote: post #59
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…

My suggestion: use a nonsense answer and use it for all of them. I don't reuse passwords but for exactly the reasons you state the answer to all my security challenges is something like "Because a kipper doesn't red the blue." Alternately have a few nonsense phrases for stock challenge questions (first car, first pet, favorite , etc.) It's better than using the real (googleable) answer. Finally, as Dale Carnegie woul…

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.

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

#92

Post by [deleted] »

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…

[deleted]

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

#93

Post by ghshephard »

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 anyways - 2010? Earlier?

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

#94

Post by simcop2387 »

userbinator wrote: post #81
mschuster91 wrote: post #33

> and should accept all UNICODE characters, too, including emoji Hell no. This WILL lead to disaster, especially if people store their passwords in managers that may or may not mess up Unicode. UTF-8, for example, allows to encode the character "ä" as \xc3\xa4 OR \x61\xcc\x88. They look visually identical, yet fail any string comparison. Not to mention the support calls "I'm in $random_foreign_country and don't have…

Personally, I think passwords should be opaque sequences of bytes that just happen to be mostly easily input on a keyboard, but I agree with the warning: some might even consider such a warning a good thing.

The problem with that is, which keyboard? USA, German, UK, Japanese?

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

#95

Post by cmurf »

serge2k wrote: post #41

The don'ts list is pretty much a christmas present from NIST. I hate all of those things. Worst is the stupid security questions.

Apple still uses those and it annoys me. Yes, others still use them too, but I give Apple extra crap because I think they should know better by now but either they don't or don't care.

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

#97

Post by OptimalRoasted »

koolba wrote: post #91
1_2__3 wrote: post #59

Earlier quoted context omitted.

My suggestion: use a nonsense answer and use it for all of them. I don't reuse passwords but for exactly the reasons you state the answer to all my security challenges is something like "Because a kipper doesn't red the blue." Alternately have a few nonsense phrases for stock challenge questions (first car, first pet, favorite , etc.) It's better than using the real (googleable) answer. Finally, as Dale Carnegie woul…

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.

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

#98

Post by bleachedsleet »

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…

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.

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

#99

Post by ckozlowski »

jrochkind1 wrote: post #83
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…

Presumably Microsoft would add a salt before losing all that business. Perhaps only if you turn on special NIST-mode, in the way of microsoft and backwards compatibility. It might break some functionality, but probably not as much as moving to an entirely different product if you have things written against MS APIs.

This is a great example of how smart standards can leverage incredible pressure against vendors to adopt best practices.

What will happen is that if the new standard is accepted as is, every single implimentation will have to craft a Plan of Action and Milestones (POAM), and every security officer is going to write in "Waiting for vendor fix". That's a lot of pressure on Microsoft to change this.

Will it take time? Certainly. Years in fact. But if you want massive change, this is how you start.

I'm a big fan of Active Directory. But I applaud this move. I'm even more excited to see if this will filter down to banks. Probably not as quickly, but one can hope.

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

#100

Post by e28eta »

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 1Password for time-based one time passwords. They're very upfront about the limitations, and I'm comfortable with the tradeoff, especially since it has eliminated the hassle of setting up Google Authenticator repeatedly.

https://blog.agilebits.com/2015/01/26/totp-for-1password-use...

Post reply on HN