
Ask HN: How can we expect users to create these passwords? - anon1m0us
Password requirements for a government website:<p><pre><code>  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 (&lt;), 
     greater than (&gt;),
     left bracket ((), 
     right bracket ()),   
     apostrophe (&#x27;), 
     quotation marks (&quot;), 
     forward slash (&#x2F;), 
     backslash (\), 
     and ampersand (&amp;)
</code></pre>
You also cannot CTRL-V (paste) into the password field.<p>How did it get like this? How do we fix it?
======
pwg
> 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.

------
austincheney
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...](https://www.cleartechgroup.com/why-do-passwords-have-to-be-so-complicated/)

~~~
jaclaz
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](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://csrc.nist.gov/publications/detail/sp/800-63/2/archive/2013-08-29)

[https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf)

~~~
larkeith
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.

------
ChrisGranger
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.

~~~
pwg
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.

------
zxcvbn4038
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.

------
cmurf
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.

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

~~~
pwg
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.

