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

61–70 of 237 posts

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

#61

Post by sesutton »

rdiddly wrote: post #13
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 just use the security questions as another password, like my favorite color is JyQ|l[Duc-I6KrU-0k and I went to elementary school at ?YfBW+Yurh@m$lml":.

There are some companies that make you choose from a list of answers too. United Airlines is one.

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

#62

Post by _kst_ »

ryanlol wrote: post #19
zwily wrote: post #15

Earlier quoted context omitted.

Those are rough when a customer service rep asks you for one of those over the phone... :)

On several social engineering calls I've had reps who were happy with just "it's just a bunch of random characters, would be a little silly if I tried to read it out"

Wow, that's disturbing.

Perhaps I should say that my first pet's name was "mellower retry audited grieves" rather than "esrhciaiyzhkj". (Both are random, and both have very close to the same information content given the dictionary I used.)

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

#63

Post by [deleted] »

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…

[deleted]

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

#64

Post by kibwen »

ipunchghosts wrote: post #40

How the f@@@ on the year 2016 we have a 64 character max length password requirement!!

That's a minimum maximum requirement. It says that the password must be allowed to be at least 64 characters long, not that they be at most 64 characters long. Combined with the forbidding of composition rules and the demand that all ASCII and Unicode be allowed, 64 characters is more than enough.

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

#65

Post by kibwen »

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…

  > UTF-8, for example, allows to encode the character "ä"
  > [...]
  > I believe that it makes sense to display a warning
Both of these are addressed in section 5.1.1.2:

"If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings defined in Section 12.1 of Unicode Standard Annex 15 [UAX 15] using either the NFKC or NFKD normalization. Subscribers choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully."

https://pages.nist.gov/800-63-3/sp800-63b.html

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

#66

Post by freehunter »

mark-r wrote: post #51
freehunter wrote: post #35

Earlier quoted context omitted.

Unless you can only change on a pre-defined interval, the attacker can always change your password for you to avoid being locked out. I don't know many users who would complain their their password seemingly never expired.

These are often combined with a requirement to not reuse some number of recent passwords, so the attacker can't change the password right back again. When you can't log in then your password will be reset and they've lost access.

That's true, I hadn't thought of that. Holiday week has my brain off in the clouds.

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

#68

Post by silverwind »

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…

> They look visually identical, yet fail any string comparison.

That's a non-issue. You should normalize unicode strings to a common form (preferably NFC) before any comparision.

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

#69

Post by Spooky23 »

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…

The reality is that passwords are being deprecated as strong security boundaries.

We've been working under this fantasy that it's acceptable to make a "strong" password and have a meaningful expectation that you can maintain the security and integrity of access. Multi factor authentication is the best solution to this problem -- a moderately complex password with MFA is stinger than a password.

If you want to compromise somebody long-term, you move laterally within the targets network and infect multiple devices.

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

#70

Post by riskable »

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 administering all their Windows systems. It's not going to be pretty.

You might be thinking, "but these are just guidelines!" Yes, but actually there's loads of existing business contracts with wording that states the business must adhere to all NIST (security) guidelines. Also, you can bet that once this gets finalized other standards will follow suit.

It will be interesting to see what Microsoft does because salts were expressly not added to AD because so much functionality cannot work with random salts in place. They're going to have to break backwards compatibility with a lot of functionality and many 3rd party products that synchronize with AD. Entirely new APIs are going to need to be written.

It will also become seriously annoying to create keytabs at large organizations since only domain admins will have that power once random salts are in place; making automation very difficult.

Post reply on HN