That is seriously fucked up. I can’t imagine how the developers could think that this a good idea or why that might be even required technically.
Yes, sure — there’s some logic there. But there are many instances where a compromised password will negatively impact your community in a big way; multiple compromised passwords can essentially transform your platform into a spam factory and scare everyone else off.
Not to mention that even if a compromised password is your own fault, you’re associating that compromise with the site. Instead of visiting the “regular old site” you’re visiting “that site where my password was compromised that one time and I had to go around changing all my passwords and I feel embarrassed about all those diet pill ads someone posted under my name”.
So sure, you can set a “fend for yourself” password requirement and simply require a single character or more — but at that point you also kind of have to accept that at any point your entire site can descend into chaos.
3 Likes
I recall being asked to provide technical advice on a project bid to implement password rules. The one that got me was the request by the client to disallow passwords which were similar to prior passwords. So you couldn’t change your password from “password1” to “password2” when the password aged out. Since we were following at least the bare minimum of good password management (salted hashed passwords), we pushed back on that request – how would we know how similar the password was to older ones?
I use a password manager that runs locally on my machines, with its database under my control, so I’m not reliant on a 3rd party. If course, if I don’t back it up, or otherwise lose it, I’m still screwed.
I hate the “we won’t tell you what the password rules are until you break them” system. Alexander_Wright’s post really rings true to me, especially the “some special characters are more special than others”. If you are hashing your passwords anyway, what does it matter which special characters are used? Or length? Or any of these limitations blocking good passwords?
3 Likes
So why isn’t “correct horse staple battery” a good password again? I can type 100 wpm, why not just let me have a passphrase? So many sites enforce all these stupid rules, but then limit the password length to fifteen characters, and often ban spaces. It is maddeningly stupid.
3 Likes
I think the most correct way is to tell person if his password is bad or not. I mean when you have rules, you just do something like “Aa1.$aaaaa” to comply to all rules, and then you’re pissed off and your password still sucks.
1 Like
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) 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.
1 Like
I’ve been using LessPass recently, which is similar to your solution I think. There’s a master password which is combined with your account login details to generate a unique password deterministically. The actual master password is never stored on a server, and the password is regenerated each time you need it.
There is an opt-in server component to store special per-site options (username, password options like length or allowed characters) but you can self-host that too if you want.
1 Like
On a financial site I use, asterisk (*) is not allowed, even though special characters are required.
On learning this, I spent some time trying to enter various bash scripts & SQLs as my password, out of curiosity. Has nobody heard of Little Bobby Tables ?!
1 Like
What’s even more dangerous with passwords rules is that people are most likely to forget it, and just use the reset my password option through email, defeating the purpose of a strong password to begin with.
1 Like
This blog post continues the same pattern I’ve seen repeated since the beginning:
- Shame existing password validators
- Suggest yet another password validator
The solution to this problem eludes most people, because most people have a propensity to babysit others. The solution is to stop validating passwords altogether. If we stop babysitting people and allow the natural economics of the situation to govern it, we’ll begin to see more people educated in the science of creating good passwords.
The natural response to this is probably something like,
That’s great and all, but we can’t afford to let people lose their bank accounts and livelihoods based on some libertarian idealism.
to which the natural response is,
A) People already are losing their things, since as we’ve determined time and time again, password validators are only relevant until they aren’t, and B) most people lose their accounts because of social engineering, not because of data leaks and then subsequent password guessing (and especially not because of simple password guessing, since CAPTCHAs handle that).
2 Likes
One of the other things that really get my goat is when the password rules are explained to me, as a user, after I enter a password that doesn’t match them. Or even worse, if there are a set of rules I must follow, but the site only tells me the specific one I violated. Grrrr.
So…put some mechanism in place where I can see the password criteria before I take my first crack at creating one.
1 Like
I think that we need to add the 4th factor of authentication: Someplace You Are. Instead of a password, ping the user’s phone, and if it is more than 1000 meters from where they are trying to log in, they cannot.
1 Like
For another good analysis, take a look at Klaus Post’s excellent password requirements article.
He has developed a Go library for checking passwords against a dictionary, and provided a combined dictionary from several leaked databases with >1b entries.
Regarding password entropy (aaaaaaaa) you could consider running a compression algorithm over the password to check that it is suitably random: a good password should probably be incompressible. Passwords may still be too short for this to be a good estimate though. See also Kolmogorov Complexity.
1 Like
Exactly what I thought and expressed here too. Validation is bullshit but you should validate at least this and that.
Just let people decide themself and take the fucking consequences of their weak passwords.
1 Like
That requires every site you log into to have access to your GPS location. Probably not a good idea.
I don’t have GPS enabled on my phone, and I never enable location checking when I browse. But the “guesstimate” of my location is still good enough. The idea is to reduce the circle of attack from 20,000 Km to about 1. We got by with locks on our doors up to now because no one could steal your stuff unless they physically went to where your stuff was. Now, our digital stuff is “nowhere” and so are we, so the circle includes everyone on Earth. Bad design from the start. Make it physical, somehow. If someone steals ME I have bigger problems.
+1 for zxcvbn. Does a great job of estimating the entropy of passwords without imposing any particular rules.
No need to worry about length, symbols, or any other arbitrary rules. Just disallow weak passwords.
1 Like
I’ve another hint, for site developers: DON’T STORE THE PASSWORD IN CLEARTEXT. Run it through crypt() or SHA256 (I have no expertise in what’s the most secure way to do this) and store that. Unix has done it this way since it was two guys with an abacus. This way if your password list is stolen, at the very least it’s going to take some work to get the passwords out of it. It always appalls me how many sites’ password recovery screens actually show you your cleartext password instead of making you reset it.
This is why I’m a fan of passwordless login. Don’t even give your users the option of creating a password…
https://blog.medium.com/signing-in-to-medium-by-email-aacc21134fcd#.pee94gisw
4 Likes
Don’t use SHA256 or crypt… while they’re better than clear text (which is beyond appalling practice) those are not very good for password hashing because they are way too fast.
Use something like Argon2, Bcrypt, or Scrypt (with a high enough rounds for each to make it relatively slow): https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016
2 Likes