
Dumb Password Rules - Liriel
https://github.com/duffn/dumb-password-rules
======
huphtur
Joel Califa's "Patronizing Passwords" has some great examples:
[http://joelcalifa.com/blog/patronizing-
passwords/](http://joelcalifa.com/blog/patronizing-passwords/)

~~~
hood_syntax
Thanks for the article, I enjoyed the read

~~~
design
You're welcome, thanks for reading :)

------
tacostakohashi
I use KeePass to store all of my (randomly generated) passwords.

One ongoing annoyance is that it's increasingly difficult to generate a random
string will be meet a given site's Dumb Password Rules, because so many sites
have them, and there's surprisingly little overlap in the rules.

I would really like to see a database of sites and their corresponding Dumb
Password Rules, so that I can tell KeePass (or any other app using the
database) to generate me a new _Mindware_ password, or a new _Williams-Sonoma_
password, and get a random string that conforms to all the relevant DPRs.

~~~
jjnoakes
KeePass should let users configure a pattern for passwords, like "8-25 letters
or numbers or these symbols, must have 1 uppercase letter", and just replicate
that socially (the pair of web site and pattern) across all KeePass users.

~~~
scrapcode
Sounds like a good idea at first, but could also be a huge attack point.

~~~
Bartweiss
The "replicate" bit sounds deeply alarming - a password manager using social
or learned rules just screams vulnerability. If you made me guess an attack,
I'd picture someone paying for a server cluster or botnet to repeatedly assert
super-restrictive rules, and then use their knowledge of those rules to guess
the generated passwords.

Allowing some basic rule-setting, though, sounds quite nice. Arbitrary
restrictions will probably leave people setting bad passwords, but there are
some very common flags like "must have a special character" or "can't have a
special character" that it'd be convenient to access for these sites.

------
dvcc
In the same spirit, can we please do away with the idea of expiring passwords
-- and then enforcing that we can't even re-use our last X number of
passwords. It just causes locked out accounts, written down passwords or
adding on one more of whatever character was at the end.

~~~
laurencei
There is a specific reason for having "cant reuse last X number of passwords"
combined with having an "expiring password" rule.

The idea is that if someone was silently in your account, and doing a
"stealth" attack - then they could change your password, then change it back
to your original password, thus "resetting" your expiring password timer,
giving them more time in the system - and you would not know that the password
was reset. Preventing old passwords prevents this.

Note: The only flaw I never understand with the above is cant the attacker
just change the password like 10-15 times in 5mins, and thus "flush" out the
old password?

Note 2: I dont personally agree with expiring passwords - but it helps
understand the reason why it exists.

~~~
raesene6
err in that attack how do they know your original password to change it back?
and if they know your password to change it back why bother changing it in the
first place, why not just log in as you?

AFAIK the reason for password history is where periodic password change is
enforced, to prevent a user from just alternating between two passwords.

enforced periodic password change is (in the general case) not great for
security, luckily we're starting to see official guidance which recognizes
this [https://www.ncsc.gov.uk/guidance/password-guidance-
simplifyi...](https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-
your-approach)

~~~
neohaven
Let's say a service does not require you to change the password. You are then
"compromised once, compromised forever", at least until you change the
password.

Let's say it requires you to change it every month. You are compromised at max
for a month, right? If the attacker changes the password, you will notice, and
_make a different password_ , which will lock them out since they don't know
the new one. So they won't change it, but they will lose access next month.
This is good...

Except if you allow repetitions of old passwords. In this case, the attacker
can change your original password to 'aaaaaaaa' for a moment and re-change it
back to the original one, which will reset the "one month" timer, leaving them
with access. Until you change it, but the platform won't bother you with it
since the timer never expires.

~~~
raesene6
I've done many password audits over the years and all monthly password changes
does it make people use sequence passwords (e.g. MyPass1!, MyPass2!, MyPass3!)
which are easily guessed by the attacker once they have one instance of the
sequence, so really monthly changes add very little in exchange for the hassle
they introduce.

The more sensible approach is not to force periodic change and only change
where there is a suspicion of breach.

------
laurent123456

        > - Must be at least 8 characters long
        > - Include at least 1 number
        > - Include at least 1 uppercase letter
        > - Include at least 1 lowercase letter
        > - May use special character
    

"Password1"

~~~
nobodyshere
Could be shorter.

~~~
jjawssd
Passw0rd

~~~
nobodyshere
Now that's what I call security.

------
0XAFFE
Popular German bank „Sparkasse“ has this great online banking system that
allows you only 5 characters (Small and large, numbers, umlauts and eszet[1]).
They call it a PIN (Personal identification /number/), but IMO its terribly
insecure.

[1]
[https://en.wikipedia.org/wiki/%C3%9F](https://en.wikipedia.org/wiki/%C3%9F)

~~~
duffn
This is the second time I've now heard of this since starting the repo. I
cannot believe an online financial institution allows this.

Feel free to submit a PR if you like.

~~~
0XAFFE
@duffn is ok if its in german?

~~~
duffn
Sure. If you could also provide a description in English as well I think that
would be helpful. Here's a non-English example:
[https://github.com/duffn/dumb-password-
rules#movistar](https://github.com/duffn/dumb-password-rules#movistar)

------
choward
My favorites are the ones where you can't use more than a certain number of
characters or where you can't use special characters.

~~~
adrr
Amex website had their max password length of 8 characters. Not sure if they
changed it. Even if you do have a system constraint, you could just lop off
the extra characters and the user wouldn't probably never notice.

~~~
jlgaddis
Mine is way more than eight characters (randomly generated w/ KeePassX),
although I haven't tried truncating it to eight and seeing what happens.

------
ryandrake
Something I've always disliked about password rules is the "special" treatment
of special characters. What makes one character special and not another? Is %
special? Why? Can I use ½ in my password and have it count as a special
character? How about 特别? What about Ѕ, Κ, and о? Does "special" mean non-
ASCII, non-alphanumeric, not-on-the-keyboard or something else? Why is it that
sometimes some "special" characters are allowed and others are not, even if
they're right next to each other on the keyboard? Why require one? Is
"P@ssword" really better than "correct horse battery staple"?

~~~
x1798DE
I think generally people stick to ASCII printable characters because of the
support cost, since the benefit of allowing non-ASCII passwords is not
generally worth the headache of dealing with customers who find themselves
trying to log in to their account a terminal that isn't configured for the
character set their password is in.

As for other special characters, a properly implemented password storage
system would just dump these directly into a key-derivation function before it
ever touches a database, but I think you get those rules from a mix of: 1.
people who are storing their passwords in plaintext and are worried about SQL
injection attacks and 2. people who know to pass them to a KDF before storing
them in the database and either have inherited some old rule about "no special
characters" or who are not convinced that someone in the future won't make
changes to the system such that special characters would become a problem, and
are trying to make it more robust to potential reversions.

Not saying it's a good idea, but at least some people "doing things right"
will still have somewhat reasonable concerns about special characters.

------
lorenzhs
My bank limits passwords to at most 5 alphanumerical characters. Yup. Five.
There are over ten times more possible customer IDs (10 digits) than
passwords.

~~~
vinay427
Out of curiosity, what bank is this?

~~~
lorenzhs
The Sparkassen in Germany do this, but they're not alone in doing so. They
lock you out after a couple of attempts, so brute-force is out, but it's still
dumb.

~~~
clarkcox3
> so brute-force is out

Until someone gets ahold of a list of the hashed passwords and can brute force
them at home without triggering the lockout.

------
pilif
Some of the restrictions of special characters I can somewhat understand:
Depending on the keyboard layout, many of these often disallowed characters
require proper right-alt support to be set up in order to be typed.

People tend to get these wrong or to be unaware of the currently set keyboard
layout which will cause support issues.

Same goes for non-ASCII characters where this also depends on the browser
configuration and version as they still get the encodings wrong at times.

Yes. For us advanced users using password managers this is a non-issue as
we're pasting anyways, but for people typing the passwords manually, this can
be a problem.

Case in point is me setting up new linux boxes and always using a safe initial
password (long but pure ASCII) knowing that I'can't be absolutely sure I've
configured the keyboard layout correctly. I've started this practice after
having been forced to force-reset my password via the `init=/bin/sh` boot
argument as the first step after the install :-)

What I absolutely don't get though is maximum lengths on passwords. You should
be hashing them anyways, so setting a maximum length is completely pointless.

~~~
Nadya
What? If a person is using a password that contains such a character, they'll
know how to type it or at least find it to copy/paste...

QWERTY isn't the only keyboard layout. Nor do you need right-alt support to
type things like é or ç, you just need to enable the US-International Keyboard
layout (on Windows, I'm sure equivalents exist for other operating systems).

 _> Case in point is me setting up new linux boxes and always using a safe
initial password (long but pure ASCII) knowing that I'can't be absolutely sure
I've configured the keyboard layout correctly._

That is smart for an initial password that you change once you know your
keyboard is configured properly. A temporary password while spinning up a new
machine isn't too big of a security deal if you're going to be changing it
within a few hours anyways.

~~~
pilif
_> What? If a person is using a password that contains such a character,
they'll know how to type it or at least find it to copy/paste..._

I have had to deal with people not being able to type their passwords because
a character wasn't on their current keyboard of choice (some people use iPads
and don't know how to type a # for example)

 _> you just need to enable the US-International Keyboard layout (on Windows,
I'm sure equivalents exist for other operating systems)_

you're giving way too much credit to the knowledge of the average computer
user.

~~~
Nadya
_> you're giving way too much credit to the knowledge of the average computer
user._

If they're creating a password with ß in it I'm assuming they know how to type
ß, yes. I don't expect the average user to know how to type ß. :)

~~~
detaro
And then they travel and use a different device with a different keyboard
layout and suddenly they _don 't_ know how to type ß anymore.

~~~
pilif
Also that ß submitted by one browser is \xc3 \x9f in one browser and \xdf in
another and \xe1 in yet another. Sure - if the client behaves correctly, you'd
know what it arrives as, but some browsers don't and suddenly the password
'foobar' can be used to log-in, but 'foßbar' can't.

By not allowing non-ascii characters in the first place you remove a whole
class of support issues.

------
prashnts
While we're at it, can we also shame the banks which ask you "third", "fourth"
and "ninth" character of your password + date of birth to login? Clearly
they're storing the password in Plaintext (otherwise the "random" characters
can't be matched).

I know Thomas Cook did this with their pre-paid forex mastercards which I
happen to use while travelling abroad.

~~~
x1798DE
It's a horrible practice that reduces the entropy of your password a huge
amount, but it's possible to generate these things without storing them in
plain text. Like if you know you're going to ask for 6 of the 9 characters
every time, you'd just pre-hash whatever subset of 6-character passwords you
plan on using. Of course, this turns a 9-character password into at most 84
six-character passwords, so assuming they allow all printable ASCII
characters, you go from 1e18 possible combinations to 84 passwords of 1e12
possible combinations - of which you have to crack two, with the second one
being 100000x easier than the first, so overall the password is ~1,000,000
easier to crack from the hash. I imagine in most cases it's actually a
signficantly greater reduction in security than that, so it might as well be
plain text.

I think the idea is that they are worried that their customers will enter in
their real, full password on something with a keylogger.

------
bertr4nd
Honest question: does password strength actually matter that much in practice?
Do people using "horse" get hacked more often than using "zjh5?&Dp"? Is there
a point of diminishing returns where "horse23" is basically good enough? Has
anybody studied this in a systematic way?

~~~
Cursuviam
Yes, if an attacker gets a dump of hashed passwords, horse will be tried much
sooner than the other example.

------
libeclipse
A university that I'm applying to has a particularly stupid requirement on
their login portal, but since I'm a prospective student, I don't think it'd be
wise for me to name and shame.

~~~
Dragonai
Come back and contribute to this once they've made a decision. :)

------
sashk
CPanel -- [https://features.cpanel.net/topic/better-password-
strength-c...](https://features.cpanel.net/topic/better-password-strength-
checker)

Will say that "correct horse battery staple" isn't secure password and will
give it a score of 0/100\. While "123!" will get 66/100 and will get accepted.

And this is control panel used by many hosting companies. :)

------
makecheck
I think that if you intend to “shame” something, you should at least start out
with proper channels (e.g. send an E-mail, file a bug, whatever). Also, it’s
not really going to shame them unless you point them to the place they’re
being shamed.

In the end, what is more important: seeing the situation _improved_ or just
complaining?

------
dawnerd
I created an issue for this, but one really dumb thing is inconsistent
password verification. Bestbuy will let you use anything for a password but on
login really long passwords will trip it up. Been able to reproduce it a few
times with 64 character passwords generated from 1pass.

~~~
aggie
Why use a 64-character password? This post suggests more than ~21 random
characters (128 bits) doesn't get you extra (practical) security:
[https://security.stackexchange.com/questions/33196/is-
there-...](https://security.stackexchange.com/questions/33196/is-there-a-
length-beyond-which-increasing-password-length-provides-no-additional)

~~~
dawnerd
No good reason other than they let me. My thinking is, if you're going to let
me put anything in then your system should work with that. If it's going to
break at n characters then cap the length.

------
jlgaddis
I think the reason that many banks still have "stupid" requirements (as seen
in this thread) is because many of them still offer "banking by phone" \--
i.e. calling into an automated system and using DTMF tones to enter your
password/PIN/etc.

------
TimWolla
This is the reason I opt for alphanumeric passwords without special
characters, unless a service requires otherwise. A single extra character in
length more than makes up for the missing special characters and past a
certain point a password simply is “strong enough”.

------
lucideer
Stack Overflow is the offender that's affected (and surprised) me most in
terms of arbitrary requirements. though It's a while since I've tried changing
my password there so not sure if it's changed.

------
petarb
The Covered California website suffers from the dumb password problem. It took
me 6 tries with Last pass before I could generate a random password that
"matched" their hidden rules.

------
ManlyBread
You can add Voat to the list, it has one of the most frustrating sign-up
processes known to man. Most of the rules are hidden until you solve the
captcha and press submit.

------
a_c
Related. One local bank I've used forbid typing out password on keyboard. They
provide a virtual keyboard and you have to click your keys one by one.

------
cr0sh
What is HN's opinion on XKCD-936? Is it valid, or complete rubbish - or
somewhere in-between?

The last time I researched this, I found a number of different opinions, but
they ultimately trended toward it being a "good idea", with the caveat that
the words need to be chosen by a truly random process, and not by the user (as
then bias would creep in).

I'm not a cryptographer, though - maybe someone(s) here is and can give some
further insight?

Also - if such a password is a good thing, it would probably be best to use it
for a password manager, and let the manager generate long random passwords for
individual logins.

If XKCD-936 is considered ok, then in theory, as long as the password field
allows for reasonably long passwords (25+ characters), and simple letters and
numbers - it should be ok.

The problem would then be education (for the users and developers - plus
convincing IT/security/management) - we've all been conditioned that passwords
need to appear complex (not that they actually are for a computer). Then of
course, there's the problem that this is baked into financial/banking security
rules passed by Congress (so if XKCD-936 is correct, it basically means we've
legislated an insecure practice in place, based on faulty knowledge at the
time, for the one area where we need the most security possible)...

Thoughts?

------
fdim
How about allowing special characters and not just a-zA-Z0-9.

~~~
blowski
Usually, there is some legacy system behind the scenes that can't be updated
because reasons. Not an excuse, but it isn't always that easy.

~~~
morganvachon
I wonder if another reason may be the differences between traditional PCs and
mobile devices with virtual keyboards. I've seen special characters that are
two taps away on my phone that I'd have to look up an Alt code for on my PC.

