Ask HN: How can we expect users to create these passwords? | Hacker News Reader

Ask HN: How can we expect users to create these passwords?

14 pointsanon1m0us14 comments

Password requirements for a government website:

  Must be changed every 180 days
  May be changed only once per day
  Must contain a minimum of 8, and maximum of 20 characters
  Must contain at least one uppercase and one lowercase letter
  Must contain at least one number
  Must contain at least one special character
  Must be different from the last six passwords
  Cannot contain the User ID
  Cannot contain any commonly used words, and only two letters may be used in a row, for example: Hr1hi2Hi$
  Cannot contain any of the following special characters: 
     Question mark (?), 
     less than (<), 
     greater than (>),
     left bracket ((), 
     right bracket ()),   
     apostrophe ('), 
     quotation marks ("), 
     forward slash (/), 
     backslash (\), 
     and ampersand (&)

You also cannot CTRL-V (paste) into the password field.

How did it get like this? How do we fix it?

View on HN

> How did it get like this?

Too many users using weak passwords, too many password breaches, too many users reusing the same password everywhere, too few users using password managers.

> How do we fix it?

For existing sites, and govt. esp., it is unlikely you'll be able to fix anything.

> You also cannot CTRL-V (paste) into the password field.

1) Use Firefox 2) Go to about:config 3) Turn off (set to false) the option named dom.event.clipboardevents.enabled

No site can block your using paste in a password field again.

It got like this because a premature spec became a government department standard and then a widely used government convention and finally an ISO standard. The guy who wrote the standard these stupid conventions are based upon considers it a complete mistake. Part of the reason this really bad idea was acceptable at the time is because many government software systems were old and had limitations on storing large passwords (yes, some systems store literal passwords instead of an equivalent hash).

A better alternative is a natural language sentence containing a minimum of 64 characters and no sequence of identical characters greater than 2 that is hashed to a 256 character hash.

The military solution to get away from that stupidity is use of CAC, which rolled out about 15 years ago, and is now universal across the military.

EDIT:

It is a NIST standard and not an ISO standard

* https://www.cleartechgroup.com/why-do-passwords-have-to-be-s...

No.

It is NOT really-really a NIST "standard", as a matter of fact the mentioned NIST documents linked to in the article make a completely different set of suggestions fron what the OP listed:

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

and in any case they are guidelines that only apply to some government infrastructures and actually sport:

>These guidelines provide technical requirements for federal agencies implementing digital identity services and are not intended to constrain the development or use of standards outside of this purpose.

The relevant section is 5.1.1, apparently the NIST calls passwords "Memorized Secrets"

Here is the older version (now superseded by the above):

https://csrc.nist.gov/publications/detail/sp/800-63/2/archiv...

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

Of particular note: the current NIST standard actively recommends against every single one of the requirements listed in the OP, with the exception of username derivatives and previous passwords.

64 characters?! I use a 24-character phrase, and TBH it's a PITA to type. 64 characters sounds... painful.

Disclaimer: I a password manager for most passwords, but there are a few I need to know, such as for my workstation and the password for the password manager itself.

Just use a regular sentence. Something easy to remember with common words. It is only painful if you follow stupid rules and self-impose the pain.

I do use a regular sentence, and one that I can easily remember - I meant it's difficult to correctly type so many characters correctly when they're masked. My workstation also has a FDE system on it that will lock me out if I get it wrong 3 times in a day, so it's a bit stressful :)

No, it is a pain when you have to type it on anything but a computer.

There is no good reason to limit passwords to 20 characters. If a site requires a limit so a user doesn't try to use the entirety of Don Quixote as a password, it should still allow enough characters for a reasonably long passphrase, which should then be hashed.

An arbitrary, short, upper limit is also an externally detectable code smell of a site that potentially stores passwords in plain text.

If the passwords were salted and hashed (preferably with a KDF) then the output of the salt and hash stage would be a fixed length value, independent of password input size, making external, small, limits of maximum length unnecessary.

Instead, a statement of "maximum of X" where X is small like 16 or 20 or some other number implies that the storage for the password is a char(16) or char(20) column. Which also implies plain text storage.

Very few people actually understand and can explain security, for everyone else it seems to be a monkey-see-monkey-do situation. In this case they probably had an intern spend a week coping password policies off of other web sites then they just took one of everything.

But in reality longer free-form passwords will trump crazy rule sets like this, especially in combination with 2FA like Yubikey or TOTP (Google Auth).

I really wish I knew who was responsible for the idea of blocking cut and paste and how it got so popular. My mortgage company blocks paste on their online payment forms - I think they are hoping people will mistype the amount and they will be able to charge their fat $200 late fee. Luckily there is a great browser extension called Don’t Fuck With Paste that keeps sites from doing stuff like this, everyone should have a copy IMO.

My favorite one to hate the most is chase.com.

- Must include at least one of these special characters: ! # $ % + / = @ ~.

- Can't include any other special characters (&, <, *, etc.).

That's bad enough. But the worst requirement I've seen anywhere:

- Can't include more than 2 identical letters or numbers (aaa, 111, etc.), and can't include more than 2 consecutive letters or numbers (123, abc, etc.).

In fact a!1a$%+/a is invalid because there are three a's. Try coming up with a passphrase of 32 characters (the max allowed) where a letter of the alphabet isn't used three or more times. I couldn't do it. My password manager couldn't do it. I had to go fully random and try several times to make it work.

Egregious.

Blocking these: ?, <, >,(, ), ',", /,\,& probably came from a fear of SQL injection.

Arbitrary limitations on characters, esp. on the set of punctuation style characters like the above, is an externally visible code smell of a site using plaintext storage of passwords.

If the passwords were properly salted and hashed (preferably with a KDF) then the output when shown to humans would normally be a hex encoded string. With only the characters [0-9a-f] appearing in the hex encoded string, there is zero risk of SQL injection, so there would be no need to restrict the users from these characters.

Restricting the characters implies that some portion of the system handling the passwords will see the raw input from the user and might break should those characters appear. But a properly hashed password up front would insulate those systems from the users input. So a character restriction implies a lack of proper password hashing, and a lack of hashing implies a high probability of plaintext storage of those same passwords.

Reply on news.ycombinator.com