
Password Rules Are Bullshit - ingve
https://blog.codinghorror.com/password-rules-are-bullshit/
======
simias
I agree with almost everything but the he loses me towards the end:

> I had a bit of a sad when I realized that we were perfectly fine with users
> selecting a 10 character password that was literally "aaaaaaaaaa". In my
> opinion, the simplest way to do this is to ensure that there are at least
> (x) unique characters out of (y) total characters.

Isn't that exactly what you're complaining about with your arbitrary password
restrictions to begin with?

I mean, I can imagine that a clueless user might have the illusion of safety
if they're using something like "1q2w3e4r5t" but if I use "aaaaaaaaa" as a
password on a website I know full well what I'm doing. So why even bother?

I think there are two possible ways to look at this problem from a service
provider perspective:

\- if the user getting their password stolen is a bad thing _for you_ (i.e.,
you're a bank or something like that, and getting an account compromised will
put you in trouble), then IMO the only satisfactory solution is to impose a
password to the user. In effect these ridiculous password requirements are
exactly that, except less convenient and secure. Cut to the chase and say
"your bank password is Axei5aoc0i, write it down somewhere safe".

\- if the user getting their password stolen is not a problem for you because
it's not your responsibility to handle these issues (like a hacker news
account for instance) then just let the user pick whatever they want and deal
with the consequences. If they care enough about it they'll care enough to
pick a decent password. At most if you really want to be friendly give an
indication that a password might be weak, but please don't disallow it.

~~~
sverige
Yes and yes! Many throwaway accounts I have use some variation of the same
password, because I don't care if someone hacks my HN or reddit or youtube
account. I don't use my real name on any of them. If I lose control of it,
I'll just make a new one. (Karma doesn't pay the bills, and I don't make money
from my very excellent youtube comments; someone else does.)

This is why all these accounts get an email account that doesn't include my
real name, too. There are so many sites that have these signup dialogs that
require an email address -- why? Oh yeah, that's right, user data is the oil
that will fuel the future economy.

~~~
neikos
Two ways why I think E-Mails are useful at signup:

\- Password Recovery (this can be optional though, for my sites it usually is)

\- 'Legit Users', sending an email and having them confirmed through a code in
them gives a bit more confidence in the user

~~~
camiller
'legit users'

There isn't a day that goes by that I don't get an email intended for someone
else, often including personal information, due to a mistyped email address.
Whoever decided that email verification was a poor user experience needs to be
hit in the head with a shovel after he digs the appropriate sized hole.

If you know Catherin (PA) let her know her round trip to vegas is confirmed

Carolyn's (NYC) open table reservation was canceled by the restaurant.

Different Carolyn (CA) needs to correct email address with the walnut creak
school district.

Possible the same Catherine (PA), your financial advisor needs a distribution
form filled out.

Clint (OH), your repair at Kay jewelers in Akron is done.

Ann (FL), Thank you for scheduling an online appointment with Conley Subaru

sigh, you get the idea

Edit: Oh, and I'm going to start canceling Open Table reservations that show
up in my inbox.

~~~
Declanomous
What's even more annoying is that some sites ask for verification, but then
proceed to email you stuff even if you don't click verify. Someone in
Australia created an Apple ID using my email. I ignored the verification, but
then I got a bunch of purchase receipts from them later.

What I really wish for is a link in emails that say "I am not the intended
recipient of this letter." Normal mail works like that. You can ask the United
States Postal Service to only deliver mail that has your name on it, and if
you send back mail with someone else's name they will add that person's name
to a database that says the mail is undeliverable.

I don't want to mark these organizations as spam, but that's basically what
they are to me. I've started using the password reset to log in and change the
email preferences so I don't get these emails anymore.

~~~
codeka
I had the same problem with someone signing up for an Apple ID with my email
address.

I even tried calling Apple to get them to cancel the account, but they
wouldn't let me because I couldn't answer any of the security questions on the
account!

The guy on the phone acknowledged that of course I can't answer them, because
I didn't create them, bit their policy forbids them from doing anything
without the security questions...

~~~
Declanomous
Man, now I'm wondering if this is some sort of violation of the CAN-SPAM act.
My blood pressure goes up a little every time I get one of these emails and it
doesn't have a way to unsubscribe if you aren't the legitimate recipient.
Considering the companies that spam me the most with this irrelevant crap are
Apple and Wal-Mart, I would feel 0% bad if they lost money over this practice.

Quick Edit: I just read the Wikipedia page, and individuals cannot bring suit
against spammers (using CAN-SPAM in any case). Which is a shame really,
because spam is really really annoying.

------
nerdponx
Here's another problem that isn't discussed very much: error messaging and
failure modes.

I use a command line tool to generate passwords, and I use a password database
to store them. It has happened to me before that the maximum password length
is something disconcertingly small, like 20 characters. I would copy and paste
my password, submit, and then failed to be able to login. Why? Because my
password in the "create" page was silently truncated on the front end, but the
same truncation does not occur in all places, so I would type a longer
password on the login page then what was registered in the system and it would
fail.

Other times a password that was too long or contained whitespace would fail
with a cryptic error message, or would tell me I failed to meet some other
password rule that I know I did not fail to meet.

I don't understand how something with so many widely-recognized best practices
associated with it can be implemented badly.

~~~
koolba
> Why? Because my password in the "create" page was silently truncated on the
> front end, but the same truncation does not occur in all places, so I would
> type a longer password on the login page then what was registered in the
> system and it would fail.

Here's an even worse one than truncating the end of long passwords:
_truncating internal whitespace_

The change/reset password dialog for Apple ID does this. If your password is
"foo bar baz bam" then it will happily convert it to "foobarbazbam" but not
tell you it did so. Then when you go to log into your Apple ID on your phone,
you include the whitespace, you try repeatedly and then lock your account
(temporarily). Then you do it again...

Some general advice is:

\- Don't silently truncate anything (i.e. don't limit the length)

\- Don't silently remove anything (i.e. don't remove whitespace)

\- Don't silently transmute anything (i.e. don't convert to lowercase)

\- Don't have a password max length with a limit less than $BIG_NUM chars[1]

\- Do give the user feedback rather than silently doing anything.

[1]: _You 're hashing them anyway right? So the storage doesn't change. Though
if you're using something like bcrypt be aware of the max hashed length:
[https://security.stackexchange.com/questions/39849/does-
bcry...](https://security.stackexchange.com/questions/39849/does-bcrypt-have-
a-maximum-password-length). Also you can work around that by hashing the
entire uses password (with say SHA-512) prior to inputting into bcrypt._

~~~
vog
_> Also you can work around that by hashing the entire uses password (with say
SHA-512) prior to inputting into bcrypt._

I wonder why people are so eager to combine different hash algorithms,
especially a strong with a weaker one. If this is isn't a well-established
anti-pattern, it should become one.[1] Why? Because in some sense it combines
the weaknesses of both algorithms.

Assume your password hash is:

h(p) = bcrypt(sha512(p))

Assume in the future somebody generates a sha512() collision with p and q,
while bcrypt() holds water:

sha512(p) = sha512(q)

It follows that:

bcrypt(sha512(p)) = bcrypt(sha512(q))

and hence:

h(p) = h(q)

So any collision in sha512() translates directly to h(), bcrypt's strength is
unable to protect you from that.

Had you just used bcrypt(), you would not have been affected.

Frankly, this is about collision and not about preimage attacks (the latter
being more relevant for password cracking), but the former is usually a first
step towards the latter. Also, this example demonstrates that combining a
weaker and a stronger hash algorithms usually does not combine their
strengths, but their weaknesses.

[1] It is almost like inventing your own crypto primitives, which actually is
a well-established anti-pattern.

~~~
koolba
While the collisions themselves would increase it's not statistically
significant to cause an issue in practice. Plus the idea here isn't to
increase the strength of the overall construct. It's to ensure that all
characters that the user entered have some contribution to the final product.

What I'd consider a much worse issue is considering the following to be the
same by silently truncating things:

\- some really long password ... that ends with foo

\- some really long password ... that ends with bar

\- some really long password ... that ends with baz

The only acceptable alternatives when using something like bcrypt are:

\- Restrict user passwords to 72 _bytes_ (not chars!)

\- Hash with something like SHA-512 prior to passing them to bcrypt.

~~~
vog
_> Plus the idea here isn't to increase the strength of the overall construct_

I see. If that wasn't a design goal, this construction is sound.

------
criddell
Somebody got into my bank account and attempted to steal some money. Luckily,
we were able to stop it quickly and the bank had the money back in our account
the same day. It was pretty upsetting so I sent a letter to them with a lot of
questions about their system and eventually somebody from the inside called
me.

One of the questions I asked was why they limit password length. The (low)
limit suggests that they were storing the password rather than a hash of it.
They wouldn't confirm that was what they were doing, but their ultimate answer
to me was _stop worrying - you aren 't responsible for fraud_.

I also asked for a list of all the external IPs that had accessed my account
and I couldn't get that for privacy reasons. I'm not sure whose privacy they
were worried about, but I guess it wasn't mine. In the end, it was an
incredibly unsatisfying exercise.

~~~
bumblebeard
What bank? I wouldn't want to do business with them if that's how they handle
security.

~~~
elchief
Every bank in Canada probably. Because their back-end systems run on old IBM
mainframes.

~~~
dpc59
I changed my bank's online account password lately because it wasn't a good
password, and then I forgot my new password. Resetting my password was a
fucking joke, anyone who's acquainted with me and can do a few google searches
could get into my bank account if they had my card number. It's not just their
hardware, their whole security practices are messed up but they don't care
because the federal government insures every account up to 100k.

------
jondubois
I'm surprised that this article didn't mention the most important point about
password rules:

They force you to come up with a new password that you probably haven't used
before and so you will probably forget it.

There are websites that I don't use often where I literally have to reset the
password (and go through all the i-forgot-my-password steps) every time I want
to log in because they forced me to come up with an overly creative password.

I think most people have two or three passwords for all their apps/services;
one very secure one, one medium security one and one low security one (where
you literally don't care if you get hacked). It's not the company's business
to tell you which of those classes of passwords it deserves for its website.

~~~
x1798DE
You really shouldn't be re-using passwords across sites anyway, since all your
accounts are compromised if any of them are compromised. Since re-using
passwords is a problem solved by using a password manager, I'm assuming you're
not using one, in which case you likely won't even remember the list of sites
where you have accounts that have a shared password if you need to change it
when _any_ of the other sites are compromised.

Best to just use a password manager and keep unique per-site passwords.

~~~
jondubois
Most of my accounts use my low-security password, I don't care much if they
all get compromised. I only use my high-security password on 1 site.

Password managers are horrible - Whenever I change machines, I could never
remember all my passwords and I certainly don't want to store my passwords in
the cloud.

~~~
TillE
> I certainly don't want to store my passwords in the cloud

But you're not. You're storing an encrypted blob in the cloud. You just need a
good master password and a password manager that isn't broken.

~~~
relaytheurgency
I wonder why people still think that their passwords are stored on the
external site. It's explained on the "how this works" or whatever for most
services like LastPass.

------
paulddraper
It should be mentioned that the NIST reference Jeff sites is only a draft,
started last year.
[https://pages.nist.gov/800-63-3/sp800-63b.html](https://pages.nist.gov/800-63-3/sp800-63b.html)

It's a great one. Not only does i recommend against composition rules, but

> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily
> (e.g., periodically)

Oh, if there is a sin against passwords it is forcing quickly memoizable (i.e.
simpler) passwords.

~~~
woliveirajr
Avoid those passwords rotations:

password1 -> password2 -> password3

------
Tostino
I totally agree that arbitrary password rules are not a good thing, they
frustrate users to no end, and can make things less secure.

I really liked the zxcvbn library from Dropbox, as it allows you to catch
those really egregiously bad passwords before it's too late, but is much
smarter than any list of arbitrary rules could be. I actually wrote a similar
library (nbvcxz -
[https://github.com/GoSimpleLLC/nbvcxz](https://github.com/GoSimpleLLC/nbvcxz))
for my company which implements all of the functionality of zxcvbn (and
extends it as well) so I could use it on the server side.

------
lloeki
Travel to some other side of the world and France's CNIL recommends[0] the
following password rules as of 27 Jan 2017 (abridged):

\- if the system uses a login + password scheme: 12 chars min and mandatory
mix of all among non-caps/caps/digit/special

\- if the system uses a login + password + time-based exponential backoff rate
limiting with a baseline of 1 min after 5 tries maxxing at 25 per 24h or
lockout after 10 tries or a bot detector such as captcha: 8 chars min and
mandatory mix of 3 among non-caps/caps/digit/special

\- if the system uses login + password + environmental information (such as IP
or MAC addr, etc...) + time-based exponential backoff rate limiting with a
baseline of 1 min after 5 tries maxxing at 25 per 24h or lockout after 5 tries
or a bot detector such as captcha: 5 chars

\- if the system uses login + password + hardware second factor (SIM, U2F,
YubiKey...) + lock out after 3 tries: 4 chars

To fend off in-transit and offline attacks, the document suggests that auth
should transit sufficiently encrypted (using a cipher or method currently
recognised as strong and non-vulnerable) and passwords should be stored
obfuscated using a secure (similarly defined as strong and non-vulnerable)
one-way cryptographic function with salt (and possibly pepper since they
mention a "key", which makes no sense for one-way crypto functions).

[0]:
[https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=DCF...](https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=DCFF485B7666F100CC93BF17B5D6BB27.tpdila17v_1?cidTexte=JORFTEXT000033928007&dateTexte=&oldAction=rechJO&categorieLien=id&idJO=JORFCONT000033926715)

~~~
e12e
> \- if the system uses a login + password scheme: 12 chars min and mandatory
> mix of all among non-caps/caps/digit/special

P a s s w o r d 2 0 1 7 .

------
rcar
The most recent post in one of the Tumblrs linked through the article goes
through some of Facebook's password allowances: [http://password-
shaming.tumblr.com/post/157913813567/not-ent...](http://password-
shaming.tumblr.com/post/157913813567/not-entirely-sure-if-this-is-the-type-of)

Essentially, Facebook accepts 4 forms of the password as correct: 1) the
correct password, 2) the caps-lock inverted version, 3) the correct password
but with the first letter capitalized, and 4) the correct password + 1
character of any type. Each of #2-4 seems to be designed to prevent a failed
login for the real user under common error cases, particularly when logging in
on a phone.

Since each of those options can be easily stored as hashes (with #4 being done
by also testing the entered password with the last character omitted against
the correct password hash), the only weakness I can see this introducing is
that if hashes were leaked, there's 3 valid passwords that could be found by
an attacker rather than just 1, but with good hashing practices, that doesn't
seem like a big deal since the search space will still be quite large.

With that in mind, that seems like a user-friendly addition that doesn't
introduce any major weaknesses. Anything I'm missing that would make this a
crazy scheme to have implemented?

~~~
clubm8
Not a cryptographer, so this may be harebrained:

Would someone who has access to all 4 hashes be more able to crack said hashes
than if they only stored one?

(Or would they salt each hash with a different salt to negate this?)

~~~
rcar
Yes, it would reduce the search space three-fold (the 4th mechanism uses the
same stored hash as the 1st), and your suggestion of different salts would
prevent that since each password variant would need a separate search. Still,
the difference between looking for 3 things out of ~10^20 options vs. just 1
thing is not that big.

------
SZJX
I don't see much sense in claiming that a mere 2 digit increase would be the
crux of the problem. Sure, nowadays since most websites enforce a 8-digit
limit, most cracked passwords are 8-digit long. So what? If everybody goes to
10-digit passwords, then aren't we back to the status quo and most cracked
passwords are going to be 10-digit long as well? Also, how much does a 2-digit
increase make the brute-force computation much harder anyways? By dropping
those requirements the cracker's job can literally get much easier instead of
harder even with the length increase.

I don't think the point about random password generation is much valid either.
Since most websites just have such password requirements in place, why
wouldn't those generators just remember to put the upper case and special
characters into the final result? They might try to generate them separately
and insert them at a random position. That shouldn't compromise the password's
security right?

As a side note, I also don't get why for Chinese websites a limit of 6
characters would be a good idea, as he spends the whole article talking about
length... Surely many Chinese don't use English words (though many still do
actually), but they use pinyin, which is a way to write Chinese characters
with Latin alphabet. Literally nobody uses real Chinese characters as
passwords, and most websites just downright don't support them. Clearly he
doesn't know much about Chinese websites anyways...

In all, I think most of his articles are excellent but this one is really a
bit off the mark IMO.

------
johnlbevan2
Not mentioned:

 _Password reuse across sites._ Have some check as to whether the same
password can be used for the same username / email across other sites. I
discovered this one early; back in 2000 I was an admin for a student portal at
uni created by Virgin. As an admin I could manage people's accounts; including
reset their passwords. The field for me to change their password had their
current password; it was hidden by asterisks so I couldn't see it... until I
clicked view source on the site :/. So now I had everyone's passwords & their
email addresses; my guess is I could have taken advantage of this for at least
80% of those accounts.

 _Password change frequency._ Changing your password can be annoying; but
there is some benefit (so long as you're not changing too often).

 _Password reset rules._ If you click "forgot password", many sites still use
the memorable question with questions which are often publicly available (e.g.
to get someone's mother's maiden name, this information's on the public
record, and can often be found through someone's social media too by looking
through their contacts, then the contacts of those sharing their surname; as
their mother's maiden name will match their uncle's surname, and most people
with their surname will be friends with both their mother and their uncle).
Emailing a reset link is great; but relies on email which isn't (and some
people's mail's very unsecure; e.g. company mail can often be legitimately
viewed by the company's IT team; and that's the non-hacky scenario).

~~~
raesene6
Regular forced changed of passwords is generally a net-negative for security.

There's nothing wrong with changing if you think it's been breached or just
'cause you feel like it, but a system forcing change every 90 days is likely
to be a bad idea.

This is due to the fact that when most user groups are forced into periodic
change they will stick an enumerator at the end (e.g. password1, password2
etc) which ruins any benefit you might have got from it.

That's why we've (finally) started to see good official guidelines saying
forced password rotation is a bad idea (e.g.
[https://www.ncsc.gov.uk/guidance/password-guidance-
simplifyi...](https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-
your-approach) and [https://nakedsecurity.sophos.com/2016/08/18/nists-new-
passwo...](https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-
rules-what-you-need-to-know/) )

------
sontek
I agree 100% with these complaints about some of us don't have a choice. For
example, PCI requires:

\- Contain both numeric and alphabetic characters.

\- Users to change passwords at least every 90 days.

\- Password parameters are set to require that new passwords cannot be the
same as the four previously used passwords.

Which go against the NIST guidelines. So how do you do things that are
considered "best practices" when people like PCI require you to do them wrong?

~~~
Artemis2
I assume you are referring to the NIST SP 800-63-3, which is quite new (still
a draft).

PCI DSS follows NIST guidelines quite closely. Requirement 8.2.3 reads "refer
to industry standards (e.g., the current version of NIST SP 800-63.)". These
requirements will probably be updated at the next version of the standard (and
I hope they will!).

~~~
paulddraper
Correct. Once the NIST draft is finalized, PCI standards will likely change
quickly.

------
amelius
Reminds me of this joke:

[https://www.reddit.com/r/Jokes/comments/1v4bpa/passwords/](https://www.reddit.com/r/Jokes/comments/1v4bpa/passwords/)

------
baron816
Why not get rid of passwords completely and just send a link to log in to the
user's email address?

~~~
amatix
Particularly for sites where you're unlikely to return for months/years
(government, utilities, charities, small ecommerce sites) this is a fantastic
approach.

------
prairiedock
Can anyone explain why all authentication systems don't enforce a (say)
2-second delay on repeated password attempts? Wouldn't this solve nearly all
insufficient entropy problems?

Even a 5-character password should suffice in this situation, and a human user
would never even notice the 2-second delay. How would malevolent password-
crackers get around this?

~~~
willvarfar
Its hard to do at application level, because you might have a multi-thread or
multi-server setup.

Luckily, there's out-of-the-box solutions that are easy to set up, e.g.
Fail2ban.

Fail2ban scans your server logs, spots repeat login attempts, and sets up a
temporary iptables ban on their IP.

~~~
codelitt
I really like Fail2ban for SSH lockdowns, but I worry about using it for
repeat login attempts on an application. Depending on the application, this
could possibly lock out everyone in an office, campus, etc. For certain
critical services being used by everyone, this could cause a fair amount of
headache.

------
woliveirajr
I wonder it who designs those rules, in general, notices that when you require
"at least one Uppercase" people will just press shift for the first letter,
and when you require "one number" people will suffix or prefix the password
with the number "1" [0]. And I don't know how that would increase security.

[0] for example: [http://www.the-
interweb.com/serendipity/index.php?/archives/...](http://www.the-
interweb.com/serendipity/index.php?/archives/94-A-brief-analysis-
of-40,000-leaked-MySpace-passwords.html)

------
andrewguenther
This article starts by using an example of 8 "bad" password rules, but by the
end of the post, Jeff ends up suggesting 5 of the 8 anyway. This post really
should have been called "special character requirements are bullshit."

I'd be willing to bet that a future version of Discourse will also disallow
using your previous password as well. Then we'll get another password blog
post talking about how hard passwords are and how we need more rules for
passwords. Experience is a funny thing.

~~~
DavideNL
> This article starts by using an example of 8 "bad" password rules, but by
> the end of the post, Jeff ends up suggesting 5 of the 8 anyway.

yea, my thoughts exactly after i read it...

------
rkcr
I have to use Dashlane for work and it horrifies me that their password
requirements are so outdated. A password manager ought to know that it's more
important to have a longer password than a password with a number in it.

(See rules here: [https://csdashlane.zendesk.com/hc/en-
us/articles/202698981-I...](https://csdashlane.zendesk.com/hc/en-
us/articles/202698981-I-forgot-my-master-password-what-can-I-do-#title1))

------
Spooky23
Excess in password complexity policy is bullshit. I'm surprised Atwood would
write knee jerk nonsense like this.

If you follow the NIST guidance, it's not a problem at all. The bullshit
happens when you allow infosec people who lack applied skills and go overboard
in their analysis of policy and standards documents. Those infosec people
wrongly see increasing entropy as equating to high assurance -- in reality
increased complexity leads to ad hoc "something you have" tokens (i.e. My
complex password is written on a post it note).

You need length and complexity standards because users don't know how to
measure risk, don't understand what a good enough password is and don't really
care. So people do stupid shit like make their password "qwerty". It puts
their data and the integrity of your system at risk.

Disregarding the navelgazing about cultural insensitivity re: character sets,
a 10 character length + 3/4 of upper/lower/numeric/symbol, combined with
lockout controls ensures a reasonably high level of assurance. Again, per the
NIST guidance, if you need more trust, you need multiple factors.

------
sverige
I gave up on this long ago. I login to various accounts from different
machines often enough that a password manager doesn't always work for me. I
keep a printed paper copy of some 60 different passwords in my laptop bag in
case I need to remember one for a new machine. That printed copy gets
handwritten notes on it from time to time, which I then use to update the text
file on a thumb drive when I'm not connected to the Internet. I print a new
copy about every two months, I guess.

To add to the bullshit, it is so common that a site will have some idiotic
rule (like "must include a number," "must have at least one lower (or upper)
case letter," "must include a special character," "must _not_ include any of
_these_ special characters," "must change password every 30 / 45 / 60 / 90
days"), that I don't even get mad about it anymore. I can't even spend the
mental energy to send them an email.

Whew, thanks. I feel better now.

------
chrismorgan
zxcvbn is a library by Dropbox that makes a fairly realistic sort of password
strength estimate.

[1]: [https://github.com/dropbox/zxcvbn](https://github.com/dropbox/zxcvbn)

------
dsego
Password rules are one of those bike-shedding moments project managers and
clients love so much. To show their brilliance, they invent complex password
rules, define database field lengths and ask for infinite scroll on
everything. Can't expect a code monkey to do the job right.

------
drewg123
I just yesterday had to sign up for some bullshit "secure email" service to
read some email from my late uncle's bank. They had all the rules described in
the article, and I could not use highly secure generated passwords. I finally
settled on some super weak password with one of each requirement (char, case,
symbol) tacked on to the end. Sigh.

To make matters worse, the email looked just like a phishing attempt. Right
down to having you download some html attachment, which, after it opens,
directs you to click on something which finally takes you to the "secure
email". The whole process felt like something a scammer would come up with,
and is really not how banks should condition their customers.

~~~
emondi
I think I have the same bank, it also asks "what is the answer to your
security question" as a security question.

~~~
drewg123
At least you can put a strong generated password there!

------
snarfy
"What technical reasons are there to have low maximum password lengths?"

[https://security.stackexchange.com/a/33471](https://security.stackexchange.com/a/33471)

------
shalmanese
What infuriates me is when I attempt to login to a site with a password that
doesn't conform to their password rules, the site doesn't give any indication.
It would be so easy for sites to return an error "The password you entered
couldn't possibly be your password because it doesn't conform with the site's
rules. Here are the rules again FYI" so I can figure out what dumb workaround
I had to go with to make an acceptable password.

------
nkrisc
Serious question: given those rules, are there more invalid or valid passwords
within those constraints?

At first I thought the answer would be obvious but the more I thought about it
and did some scribbling I couldn't come up with a good answer. Math is not my
strongest skill.

Let's assume you had hashes of passwords following these rules and knew the
hashing algorithm, could the rules be so restrictive they narrow the search
space and actually make it _easier_ to crack them than no rules at all?

------
woliveirajr
Thou shall take care of the password manager, as it is a single point of
failure. Because users (=not people who read and understand news from hnews,
but the layman):

1 - won't make backup of the password manager (PM) database

2 - will forget sometimes the main password of the PM

3 - will loose the cellphone where the PM is installed

4 - will not update the PM

5 - will tell somebody else the PM password

And there will be many PM, some will have flaws, bugs or backdoors. Some will
work on iOs but not on Android. Some will mess up in same point and make users
lose trust.

And there will be sites with bad interface that won't accept copy-and-paste of
the passwords. That will require things that your random-generated password
doesn't contain. Will complain about something that it contains. Will do good
on the password but will have those stupid questions (maiden name? grandfather
name? pet name?) that you'll be able to find in any Facebook. Than the weak
point becomes the password recovery.

I just found one type of requirement that was good enough to people take real
care with the password: when the password is the one that allows anyone to
withdraw cash from their account. When there is real money in the game, people
take care.

Edit: misspelling, thanks for the warning!

------
moron4hire
We hit "peak password" somewhere around 10 years ago. Passwords are both bad
security and bad UX. Cryptographic secure keys are better security, but at the
cost of a much worse UX.

Bad UX is a defect. We need to stop giving a pass to crypto programmers who
make such shitty software. Software that is not easy to use won't be used, and
should therefore be considered as insecure as any other defective software.

------
jimktrains2
I wish we could just avoid all of this by using methods like SRP[1] where the
site wouldn't even need to know the plain-text password in the first place.
Why am I giving a "secret" to someone else?

[1]
[https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)

------
ajmurmann
I've been intrigued by trying to circumvent passwords completely. On the vast
majority of websites your password already is only as secure as your
associated email account. You control the email you can reset the password. So
maybe we can build on that? Instead of entering a password I entered a code
that gets emailed to me either manually out via link. For important things we
can airways supplement with another token from a TFA app or better TFA device.
I'd argue that this would be more secure for the average user and more
convenient for at least some users and use cases. I personally would find this
mildly annoying on my laptop where I'm already logged in to a password
manager, but convenient on my phone where logging in to a password manager is
a major pain. Cheapshark.com does something similar and as a user I find it a
great experience. It's more of an obvious fit for something like this where
your account isn't very valuable and you use infrequently, but it's really no
less secure.

------
agentgt
I find it interesting he mentions Emojis as I actually just recently wrote a
deterministic password generator that uses the Emoji annotations (for word
selection) for generating deterministic passwords from a master password:
[https://github.com/agentgt/ezpwdgen](https://github.com/agentgt/ezpwdgen)

Of course you could use the EFF word database but after trial and error I
actually like the Emoji annotations [1] better (I obviously remove short words
and non ascii stuff).

I plan on having the script show the words along with the corresponding emoji
(iterm supports emojis) to help remember. The idea being not to copy and paste
(I need practice on remembering stuff anyway... the joy of getting older).

[1]: [http://unicode.org/emoji/charts/emoji-
annotations.html](http://unicode.org/emoji/charts/emoji-annotations.html)

------
Rudism
Let's imagine a theoretical world in which every service had a 12 or 15
character limit on their passwords and no other restrictions.

Does anyone really believe that the list of most common passwords would not
contain equally inane entries as the ones presented in this article, just
modified to be longer? "qwerty" would just become "qwertyuiop", etc. People
using these passwords are just filling the minimum requirements with something
easy to remember. Making them fill more characters wouldn't really change
that.

The only reason the most common passwords are short is because so many
services allow short passwords. Users gonna be users no matter how long their
passwords need to be.

That said, I agree with the article in spirit. I hate password restrictions. I
just think that the argument about most common passwords being short is a
spurious one.

------
at-fates-hands
I think its interesting that passwords have been undergoing a transformation
as of late.

Is password hacking really still that big of a deal? I mean, most big hacks
into retail places like Target, Best Buy and others are done by getting into
their POS (point of sale) systems, or hacking their networks to get at the
customer data.

I just don't see a lot of one off doxxing to get into a persons email or
financial records. Most groups are going after the big scores, not small
potatoes stuff like a few hundred cracked password protected accounts.

I could be wrong, but it just seems like even when you protect your accounts
with a strong password and triple layer redundancy and six-step protection,
all it takes is one SQL injection or an Adobe Flash flaw and all that work is
useless because the company holding your information was lax with _their_ own
security.

------
yAnonymous
"When the DB with clear text passwords is stolen from our server, because we
haven't installed updates in three years, at least your other logins won't be
affected."

There's no better way to communicate this to your customers than complex
password requirements.

------
raesene6
On the password front, I like the new NIST guidelines (summary here
[https://nakedsecurity.sophos.com/2016/08/18/nists-new-
passwo...](https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-
rules-what-you-need-to-know/) with links to the detail) and the UK NCSC
guidelines [https://www.ncsc.gov.uk/guidance/password-guidance-
simplifyi...](https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-
your-approach) which favour far more realistic guidelines rather than the
arbitrary nonsense of hard complexity rules and forced regular password
resets.

------
voidmain0001
Who cares about remembering passwords? Like my burner mobile phones, I use
burner passwords. I use a one time password and the next time I need to log in
to the website, I request my password to be reset and use the link that is
emailed to me...

------
rb808
I resisted for a while but now always use Google or Facebook account for sites
that let me. Makes the password problems much simpler.

Special brickbat for American Express who _doesn 't_ let you use special
characters in passwords - screwing up my system.

------
noja
Rule 1 is that password rules are bullshit, but all of the other rules lead to
needing Rule 1: how are you going to explain to a user that their password
cannot be their username, or that their password needs more entropy or
complexity?

~~~
scrollaway
To be honest I think this is a problem that needs to be solved outside of the
web. We need to move towards password managers.

Of course, that comes with its own set of issues: Lose access to the password
manager = lose access to all your accounts. An attacker gets access to your
password manager = they get access to all your accounts.

On the other hand, for users who use a single 6 character word as their
password all over the web, that's essentially the same thing. You can far more
easily educate someone in picking a very strong passphrase they will never
forget, than get them to use different passwords on each website.

I have successfully converted several non-techies in my family to KeepassX
[[https://www.keepassx.org/](https://www.keepassx.org/)], which I also
strongly recommend to anyone here. I had to hold hands at first but after
explaining how it works and making sure they understand how _important_ it is,
over two years, there's never been any issues.

------
jbaviat
Saying "less than 8 chars is close to no password" is stupid. It just means,
if your service provider hosting your short password get hacked, if they store
their users password in a crappy format, then your password is gonna be
recovered.

------
m0nty
I was trying to sign up to an online gaming site recently, and my initial
password was shown as being "strong" but was rejected — not enough "special"
characters. It was 24 chars long and straight out of Keepass, but whatever.

I asked Keepass for another password; it included special characters, was 24
chars long and "very strong", according to the website. Rejected.

I then noticed that the message was telling me I could not have more than 16
characters, so I trimmed the password to something rated as "medium".
Accepted.

So yes, password rules are bullshit.

------
jasonkostempski
The biggest issue with passwords is using the same one with the same username
everywhere. I knew this, still did it with accounts I didn't really care about
(Netflix, Hulu, Skype, etc) and, of course, after 10 years of using the same
one, just about every place I used it was getting accessed by someone else
over the last few month. Writing down passwords and keeping them in plain site
in your house is probably safer than using a username/password combo that you
use a lot, on a system any script kiddie can get at.

------
djrogers
Another major problem I have with password restrictions - how about you make
sure your stupid password dialog is capable of accepting the passwords
generated by password managers? How about you just test the 5 or 6 most common
ones? I hate it when I accept the suggested password from Safari or 1password
and the stupid site won't accept it because it used the wrong kind of special
character, or didn't include enough capital letters, or worst of all - it's
too long.

grrrrrr

~~~
relaytheurgency
I've been on sites that won't allow you to paste a password in. It's so
ridiculous.

------
sdevoid
Ten years ago I thought we were all going to solve this with OpenID and strong
protections on the provider side. [1] What happened? I know a bunch of
providers moved on to OAuth which let users authorized 3rd parties to do stuff
on their behalf. And then at some point we decided v1 was hopelessly broken
and moved to v2. But today it's still the rare event where I can login with my
{Gmail, Hotmail, Yahoo!} account.

[1] U2F, authorized devices, predictive phishing protections, etc.

------
ThrustVectoring
>only 5 of the top 25 passwords are 10 characters, so if we require 10
character passwords, we've already reduced our exposure to the most common
passwords by 80%.

That's not an accurate measure. Like, take two of the example common
passwords: 123456789 and 1234567890. What do you bet that the people who'd
pick the first would pick the second if they had to use 10 characters? Plus,
attackers don't have to try passwords that fail your requirements.

------
aaroninsf
Rules are annoying; passwords are what's terrible, full stop.

They are merely the only thing we know how to do which meets the expected
constraints on auth. I can't even give them a grudging 'least bad option'
because they're so bad, in our current context and multiplicity of identities.

They are so unmanageable for normal humans we have a bunch of helpers, which
become the new single point of failure.

Yubi dongles on a keychain may well be where we're headed.

------
dahart
Password rules are especially bullshit on mobile devices where the pain of
caps (requiring shift key) and the pain of special characters (often requiring
a change of keyboard) are extra severe punishments.

A long all-lowercase pass phrase that's pronounceable is both safe and easy to
remember and easy to type on mobile devices. When I hit sign ups that require
other characters while on a tablet, I frequently decide I don't need it and
bail out.

------
Wonderdonkey
Side topic: As an end user, the worst for me software that only tells you
what's wrong with your password AFTER you've done it wrong, and then only
tells you one thing at a time even when you've made multiple errors
(dictionary word, password too short, needs one capital letter, needs one
number...). Just tell me the damn rules and let me get on with my life!

------
spython
I made a simple passphrase generator to educate the less technical folks about
the issue: [https://passphrasen.de/en/](https://passphrasen.de/en/)

Edit: and if you speak German, there is a short film about passphrases:
[https://passphrasen.de/](https://passphrasen.de/)

------
thinkMOAR
"The first rule of Fight Club is: you do not talk about Fight Club"

The first rule for passwords, you don't talk about your password rules.

------
Imagenuity
A problem with using emoji in passwords is the emoji special character
keyboard shows your recently used emoji. Brute forcing a password using the
recent emoji list certainly gives you a much smaller set to work. Also, the
Chrome browser doesn't let you enter emoji directly, but you can paste them in
(which show as two dots •• ).

------
cmer
Inspired by this, just wrote a Ruby gem that handles passwords exactly how
Atwood suggests. It's still a work and progress but I think it's off to a good
start. Let me know what you think.

[https://github.com/cmer/nobspw](https://github.com/cmer/nobspw)

------
barking
I just use the recover your password functionality over and over on many
sites. I hit some keys typing into notepad then paste that into both password
reset boxes and then paste it again logging in. Sometimes though I have to
type A1! on the end if the site requires capitals or a number or a special
character.

------
otempomores
In mockery of the socialist past someone once wrote: "wouldnt it be better the
goverment voted for a new people and dissolved the nation to get to the root
of the problem.."

"Wouldnt it be better, the admins switched to better more learned users and
dissolved the company to have the provlem get root."

------
adamweb
What do you all think of this method?

[https://arstechnica.com/business/2015/10/this-11-year-old-
is...](https://arstechnica.com/business/2015/10/this-11-year-old-is-selling-
cryptographically-secure-passwords-for-2-each/)

------
pfalke
Could someone explain why password length is so important when logging into
web services? I get that it's important for encryption, but when you implement
a web service that has rate limiting, a basic password length of say six
characters should be sufficient, no?

------
ComodoHacker
So after explaining why [existing] password rules ere bullshit, author
introduces his own ones.

~~~
andreareina
After explaining why many common password rules are bullshit, the author
presents the few remaining rules that aren't. Or rather: if you're going to
subject your users to the bullshit that is passwords, here's a set of rules
that optimize the security:bullshit ratio.

------
lucideer
While I've obviously encountered frustrating arbitrary password rules on
various small/ancillary sites, Stackoverflow/Stackexchange is the only service
I use regularly that I've hit real problems with...

------
known
[https://www.random.org/passwords/?num=4&len=8&format=html&rn...](https://www.random.org/passwords/?num=4&len=8&format=html&rnd=new)

------
jlebrech
sites that prevent pasting: apple _cough_

------
iverjo
[https://github.com/search?q=correcthorsebatterystaple&type=C...](https://github.com/search?q=correcthorsebatterystaple&type=Code&utf8=%E2%9C%93)

------
jlebrech
i'd prefer no password validation other than having to type it twice. but have
a password strength gauge, and give hints on how to bump up the strength (have
you tried using a non-alphanumeric character)

------
d_theorist
Why don't we just stop allowing users to choose their passwords?

~~~
rprospero
The main reason is that, if IT chooses the user passwords, then the users
simply forget the password. Thus, the system for resetting a lost password
becomes part of the default login process. In which case, you might as well
having a password in the first place.

~~~
lloeki
> the system for resetting a lost password becomes part of the default login
> process

So the system could basically fall back to being OTP?

------
danvoell
As a side note, if you are a website with arbitrary rules, as a general UI
recommendation, please state your rules if a user inputs an incorrect
password. I'm looking at you yahoo.

------
aabbcc1241
If the salt for every user is the same, is it a good practise to check the
password hash against existing's (registered) and reject a duplicated password
?

------
empath75
Why don't we dispense with the pretense that passwords should be human
readable strings of characters at all, and just make them a sequence of
randomly generated bits.

~~~
krapp
Passwords often need to be human readable because, in practice, humans often
need to memorize them and then enter them from memory, or write them down on a
piece of paper first, which can be error prone with a complex password.

Using a password manager isn't always an option either - there is a vast
amount of infrastructure, much of it corporate and nearly immutable - that
simply presents the user with a password prompt and expects them to get it
right.

It's only recently that some password prompts even let you view the password
you've typed. With a terminal, you get no visual feedback at all.

~~~
vacri
Password managers suck as soon as you need to share a password - like the
password for a SaaS admin panel used by several people at a business. Not all
services support multiple users (or multiple _admin_ ) users.

------
oleksiyp
I use a "GetTh1ngsDone" password with my goal in it and thus type every time a
thing that I want to achieve. Isn't it a great idea?

------
syrrim
The trick of password rules should be (and this is what xkcd was getting at)
to trick users into using passwords that they find easy to memorize, but are
still high entropy. Long passwords can be high entropy, but, as highlighted at
the end, they can just as easily be low entropy. If they needed to memorize it
quickly, most users would pick a low entropy long password. Also, every users
opinion of what makes a long password easy to memorize will be about the same
- repeated letters, patterns on the keyboard, english words. This means that
you can try to detect easy to memorize password, and flag them as bad.
However, users will find something easy to memorize you don't block, and use
that instead. This new thing will probably be common to all users as well. I
once had someone inform a group that they should all use the first three
letters of their names to overcome a password restriction. While the
restriction probably assumed people would pick a random three letter string,
they instead chose an even more obvious one then they would have otherwise.

When making password restrictions, try to force every user to come up with a
different opinion of easy to memorize. For example, you could display pictures
of ten foods, and ask users to pick their favourite food. Since eveyones likes
different food, their choices would probably have a relatively even
distribution. Moreover, upon returning, each user would reidentify the same
food as their favourite. By extending this to a larger field of subjective
values, you could make the overall datapoint high entropy, while maintaining
memorizability.

------
vacri
In the 'top 25 most common passwords' bit, what are the patterns behind
'18atcskd2w' and '3rjs1la7qe'?

------
natmaster
The worst rules are the ones that don't let you use non-alphanumeric
characters - and these are banking sites!

------
deckar01
I would rather allow any password of any length and just communicate clearly
how long it would take to be cracked.

------
andrewclunn
mysecretpassword > Ae2!_jT7

from a security standpoint. I hate the required special characters BS,
especially since other sites will explicitly restrict you from using those
same characters. Seriously, without a password manager of some kind I don't
know how people can function online.

------
curun1r
This is perhaps not the place for this, but as a user of a password manager,
here's and idea in this area that I've had for a while.

I'd like the various password manager vendors to get together and produce a
standard/specification to take us (users) out of the process of registering
and rotating passwords as much as possible in much the same way that they have
the login process. Among other things, the spec should define a format for
expressing password validation rules, a password rotation endpoint/policy,
common registration fields and a url handler for triggering the registration
process.

So then site operators could add a "Register with a Password Manager" link
that, perhaps, looked like:
"register://example.com/path/to/registration/policy.json" The various browser
extensions could easily recognize that and change to "Register with 1Password"
or "Register with LastPass" or whatever is appropriate. That policy document
would have the registration endpoint, rotation endpoint, rotation period,
password rules, required registration fields, what sort of identifier is used
(username, email, etc), terms of service and possibly and endpoint for
determining the uniqueness of potential usernames. Clicking the link would
open up the password manager where the user would agree to the terms of
service, enter any missing fields, approve the sending of fields the password
manager already knows about and select a username, if necessary. Once
completed, the password manager would generate a legal password of maximum
length/complexity, send everything to the registration endpoint and save the
login details, terms of service and rotation endpoint for future
use/reference. Over time, the password manager could update the password in
the background to limit the danger should the password be compromised.

I'm curious whether others think this could work. I realize there's an
[http://xkcd.com/927](http://xkcd.com/927) problem in it, but it seems like if
all the password manager applications could agree to work together, enough
site operators would be willing to implement it that it could be useful. And
if enough people saw "Register with a Password Manager" links during the
registration process, they might get curious enough to start using one. But
most of all, I'd like to stop having to care about what a site's password
policy is...just let sites make the decision and offload the responsibility
for adapting to it to my password manager.

------
Double_Cast
> 18atcskd2w

> 3rjs1la7qe

I wonder what these two mean.

