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

71–80 of 237 posts

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

#71

Post by elchief »

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…

SMS 2FA is only as strong a your voicemail password.

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

#74

Post by hexane360 »

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…

Pafwert [1] creates the absurd really well.

[1] https://github.com/m8urnett/pafwert

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

#75

Post by helper »

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…

Will requiring salts break ms-chap-v2?

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

#76

Post by hexane360 »

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…

Now use a couple words not in the top 10,000. Suddenly your complexity goes waaay up.

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

#77

Post by nickik »

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…

You can buy a Yubikey, use the Yubikey Authenticator instead of the Google Authenticator, its more secure by far, and you can use any Android device at any time.

Or use a Cloudbased system, LastPass Password Manager for example does this. Authy does the same thing.

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

#78

Post by nickik »

foxylad wrote: post #53
freehunter wrote: post #46

Earlier quoted context omitted.

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 got a U2F key, which neatly solves the problem as long as you have a USB port. The integration into the browser makes it painless and fast to use. Adding bluetooth to work with mobile devices would make it a complete solution. Edit: corrected U2FA to U2F.

How does a U2F key help you? Most places don't support U2F.

Bluetooth and NFC are standardized, and the first products are out. I really hope U2F and UAF are gone 'make it' in the market.

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

#79

Post by dpark »

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…

Password rotation doesn't fix that because the difference between myLongPassWordThatDoesntChange and myLongPassWordThatRotates7 is effectively meaningless. An adversary who has your current password can almost certainly guess your next one because changing the 7 to an 8 is a pretty obvious step, and it's one that most people do when forced to rotate.

Forcing password rotation guarantees that most people will just use the shortest possible password and stick some rotating suffix on it because your policy is pointless and annoying. You make yourself the adversary when you enforce policies like this and people stop trying to be secure and just try to get on with life.

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

#80

Post by nmjenkins »

colanderman wrote: post #28
derefr wrote: post #10

Earlier quoted context omitted.

> Is there any valid reason for this? If they know that at some point they'll have to ask you to enter your password over a restricted input-method (e.g. on a DTMF keypad.)

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. So feel free to use as many spaces as you like in your password!

Post reply on HN