
Bad Password Policies - edward
http://www.davidpashley.com/2014/04/16/bad-password-policies/
======
axefrog
I find it extremely frustrating how many services (Microsoft included!!) won't
allow me to use spaces in my passwords. Why on earth do they care which
characters I choose for my passwords? So much for "correct horse battery
staple"...

~~~
rtpg
you can try camelCasing your passwords, same effect really

~~~
kijin
Unless the website silently lowercases all passwords. A lot of them do, in the
name of making life easier for people who have Caps Lock on.

~~~
alistairjcbrown
IIRC Facebook creates three passwords to deal with character case issues; the
one you enter, an inverted case version and a version with the first
characters case inverted.

~~~
jsmeaton
I'd be very surprised if they created all 3. They probably check the other 2
variations if the first one fails though:

    
    
      if (entered == password || entered.swapcase() == password) .. // etc

~~~
r00fus
In order to be performant, since the check is not against your actual password
but just against a stored hash (salted/bcyrpted/etc), I wouldn't be surprised
if they simply stored all 3 hash results.

------
prohor
I'm always scared when I see the maximum length limit in password. I expect
they just put clear text in their DB. Otherwise why would they limit it? Any
key deviation or hash function will give the same length, regardless of the
password length. Scary ...

~~~
smnrchrds
Maybe they're just trying to protect against denial-of-service attack through
very long passwords[1]. Although 16 or 20 characters seem too short.

[1]
[https://www.djangoproject.com/weblog/2013/sep/15/security/](https://www.djangoproject.com/weblog/2013/sep/15/security/)

~~~
twelve40
Yes, it's probably actually necessary to introduce some kind of limit to
protect the server against hashdos-type attacks. Sadly though, Occam's razor
suggests that the "20 char" limits and ridiculous "alphanumeric only"
restrictions are caused not by some advanced considerations but by something
much more stupid and incompetent.

------
MattBearman
I think the OP _should_ name and shame the site that takes passwords over a
non-secure connection, stores them in plain text, and silently truncates long
ones. Maybe that would get them to fix it.

~~~
paulannesley
That could do more harm to the site users than the site itself. Especially
with people sharing passwords between sites.

I guess that's an example Full Disclosure vs (as an alternative) Coordinated
Disclosure;
[http://en.wikipedia.org/wiki/Full_disclosure_(computer_secur...](http://en.wikipedia.org/wiki/Full_disclosure_\(computer_security\))

------
maxk42
Please do not enforce character set or maximum length restrictions. I have a
number of 30+ -character passwords that are regularly rejected because they
don't contain a digit. I'm sorry but "Password1" isn't going to be stronger
than that.

Also, consider enforcing higher minimums. Eight characters is simply too fast
to brute-force.

------
EGreg
In apps built on our Q Platform, the default "set password" screen actually
encourages users to select a PASSPHRASE and displays several suggestions. When
the app is online, the suggestions consist of three consecutive words in Yahoo
News. If the app is offline, they are generated from a dictionary in the form
MY NOUN VERB HIS NOUN or similar.

This should hopefully help more people choose strong passphrases.

------
ozh
Honestly, I don't get why a service would enforce a password policy at all.

They should _warn_ users about what makes a good password, and tell them when
their password sucks ("your password is weak and would be crackable in 3
minutes") but if someone wants for some reason to use 123456 as a password,
that's their own problem.

~~~
thisishugo
For services where a user can only access their own account, I mostly agree.
But sometimes one users' bad security practices can compromise other people's
security, too. If you're sharing confidential data with other people - for
example, via SpiderOak[0] - and any one of those people's accounts are
"hacked," it doesn't matter how good your password is.

[0] I'd say Dropbox, but you shouldn't be putting confidential data in
Dropbox.

------
joshka
What's a reasonable minimum max password length? I've always fallen back on
the Wikipedia Password strength article [0], for the NIST recommendation that
80 bits is sufficient entropy. I imagine that attack vectors other than
password strength are for the most part going to be the killer issue.
(heartbleed, MITM attacks, rubber hose, tempest, etc...)

Assuming that we're talking about purely randomly generated passwords, the
entropy of passwords generated to fit in at least a few of the cases in the
the original article should be fine. The UX factors are annoying however. This
is an area where consistency would assist conformance.

[0]
[https://en.wikipedia.org/wiki/Password_strength#Bit_strength...](https://en.wikipedia.org/wiki/Password_strength#Bit_strength_threshold)

------
chrismcb
It seems to me the more secure you want your data, the more arcane (and less
secure) the password rules are. I recently got in an argument with the bank,
that doesn't allow special characters "These rules are here for your
protection" Then why are you limiting the input space. "It is for your
protection, so it is more secure." Rules like these, (limited length, limited
set, etc) scream to me incompetence. And I wonder what else is broken.

------
ygra
Any length and any character is a nice idea, but given an incompetent
developer on the other side it can get worse. E.g. a frequent snippet you can
find on the web for hashing a string in .NET uses things like Encoding.Default
or even Encoding.ASCII. Those then change every Unicode character silently to
a question mark, making a lot of potential passwords identical. Normalisation
should also be considered and rarely is.

------
1ris
My bank does not allow me to choose a password with more than 6 chars (but
that is only the log in, for any actual money transfers there is a
factor-2-auth), and i think icq did limit the password to 8 chars.

The only reason i can think of why one should do this is plausible deniability
for the provider. No, we weren't hacked, your password just sucks.

~~~
pritambaral
This approach to "plausible deniability" can backfire easily. You made my
password suck.

------
Orangeair
One of the most ridiculous password policies I ran into recently limited
passwords to a _maximum_ length of 8 characters. I was absolutely stunned. And
for whatever reason, they also enforce that it must contain both a capital and
lowercase letter and a number, plus a minimum length of six characters.

~~~
ajanuary
My university used to have a similar length restriction. When I enquired about
it, it was because they unify the password across all their systems, and some
of the systems are old.

------
ateevchopra
I have one question. Even if we use hashing and random salting, then should we
make some max-limit on the password. Its not related to the length i want to
store, its the length that system will convert to a hash. Will very long
passwords be hashed in equal time ?

~~~
kijin
A long password does take a bit longer to hash, but taking a long time is the
whole point of modern hashing algorithms like bcrypt, so you shouldn't balk
merely at the fact that it takes longer.

The real problem is that if the password is too long, it will kill your server
to compute a hash of it. So there needs to be a limit. The usual limit in my
apps is 1KB. bcrypt is fast enough to hash 1KB with a work factor of 10 (a
reasonable default on current hardware), and I have yet to come across any
realistic situation where a password over 1KB is needed. After all, the heat
death of the universe will probably occur sooner than you can brute-force it.

I'm willing to increase the limit a bit if someone really wants to use a 32KB
password. But 1MB is probably overkill. 1GB is definitely off limits.

There is, however, another problem with using bcrypt to hash long passwords.
bcrypt ignores everything after about 60 bytes, so the password is effectively
truncated. This can be a problem if most of the entropy is in the last part of
the long password, because long passwords that only differ at the end would
produce identical hashes given identical salts. (Imagine that someone uses the
Fifth Amendment as his password but changes a few words in the last clause.
What if someone types in the unmodified Fifth Amendment? Boom, they're logged
in.)

My current solution for this problem is to do something like
bcrypt(sha512($password)) so that I never need to feed anything really long to
bcrypt. (The raw binary output of sha512 is 64 bytes long.) But I'm not sure
whether this might negate the benefit of using a very long password in the
first place, so I wouldn't recommend it unless someone who knows better can
confirm that this is safe to do.

------
phillab
As soon as some characters are not allowed for passwords I always fear that
the service did implement own hashing and password storage methods instead of
using standard ones

------
paulannesley
It seems reasonable to enforce a size-limit on passwords, but in the order of
kilobytes, not a two-digit number of characters. Perhaps 64 KiB, to
commemorate Heartbleed.

------
user24
Please someone set up a tumblr for these.

Paypal has a max of 20 chars.

~~~
cheepin
I can't remember which site did it, but one site would just silently fail and
redirect to the same page if the password was too long... awkward.

------
user24
See also: [http://plaintextoffenders.com](http://plaintextoffenders.com)

~~~
Grue3
And the very first complaint is about a site sending you a password after
registration, which is safe unless your email is compromised (in which case
you're screwed anyway).

~~~
user24
and it has a disclaimer to that effect;

> On the plus side, they don’t send you your plaintext password if you click
> on the forgot password link, so maybe they don’t store it in plaintext.

------
DrJ
American Express also has 20 character limit, but for more fun they are case
insensitive.

------
jbverschoor
It's the service's job to be protected against bruteforce attacks.

