About two years ago, I wrote a little function to calculate the complexity of a password based on the usage of character classes. My goal was to not force people into adding '123!' to their password just to use all character classes, but instead allow pure character passwords with an equivalent complexity. That way the user can choose if wants to use an 8 character password with upper case, lower case and numbers or a much longer password with lower case letters only (or something in between).
The function is far from perfect as it was just the first implementation of that idea and never run in production. But I think as a base for a discussion it should be good enough.
function passwordComplexEnough($password){
$chars=0;
if(preg_match('/\p{Lu}+/', $password) === 1){ // letter upper case
$chars+=26;
}
if(preg_match('/\p{Ll}+/', $password) === 1){ // letter lower case
$chars+=26;
}
if(preg_match('/\p{Nd}+/', $password) === 1){ // decimal digit number
$chars+=10;
}
if(preg_match('/\p{S}+/', $password) === 1){ // symbol
// seems pessimistic but reasonable
$chars+=10;
}
$len = mb_strlen($password);
$complexity = pow($chars, $len);
// 62^8 (62 chars and length 8 as minimum complexity)
return ($complexity >= 218340105584896);
}
I think it might be useful as a hint but if you're trying to enforce good passwords it falls short like every other scheme. For instance if I'm not mistaken "PasswordPassword" would be accepted by your function.
I always think there are two ways to look at the password issue:
- It's the user's responsibility and you live it up to them not to use something stupidly weak if they value their accounts (at best you can hint them that the password is weak, but if they want to use "qwerty1234" you let them). This is the approach I expect from websites like HN, reddit, and the like.
- You want to protect the user and yourself, maybe because you're a website handling money transactions or you're a corporate website and you want to make sure every user has a decent password to access the company's resources etc... In this case the only satisfactory solution is to enforce strong 2FA and if that's really not an option then generate the password for the user. Otherwise they'll always figure out a way to reuse their passwords, generate a weak passwords that passes the predicate etc...
Because in the end, while I'm sure most people would agree that "oothe*Nah2phao0t" is a very strong password, what good is it if I reuse it across a large variety of websites? What about phishing and social engineering? I'm going to go out on a limb and guess that there probably are more Facebook account hacked because of password reuse and phishing websites than people blindly guessing passwords.
Apparently one of the more common passwords are "Password2018" (or 2017, 2016 etc, depending on current year). Nice and long, mixes three character classes. Not very secure...
Seems reasonable, though there are some strings that pass that happen to be in precomputed rainbow tables, like "0xDEADBEEF" or "secretpassword". Nothing's perfect though. Passwords just suck.
“Every single minimum password length is an even number!”
You JUST mentioned that Wikipedia requires 1 character.
“There's no 5 or 7 or 9, just nice, round, symmetrically even numbers.”
What do you mean by round numbers? Obviously not 10, 20, etc. So do you mean that the minimum lengths should have decimal points?
All jokes aside the article of course does make some good points
I think what he meant is that Wikipedia does not have an explicit requirement. The password has to exist as a string so there's an implicit 1 character requirement, but there exists no explicit requirement.
The best ones are pages where the register dialog only allows a max length, silently truncates it and then the login dialog allows every length. And then you start to search why the password you generated ten seconds ago doesn't work anymore. So much fun .. not.
This bothers me to no end. Generate a new password, everything seems fine. A week later when I want to login again, suddenly the password doesn't work. After resetting the password and changing it again, I notice the little "max 12 characters length" message but it doesn't warn you, just silently truncates.
So nowadays, when I change my passwords, I have to make sure I don't hit the length limit, and after changing the password, confirm that it really changed to what I want to. In the few cases where it doesn't, I need to go through the entire dance to reset my password again...
In discussions of whether there should be a maximum password length at all, it's funny to introduce the scenario of a user wanting to use a password that is 1GB worth of text.
I always wondered about that too- I recently came across a discussion somewhere that the password limit should be the max allowed for the POST to that website. Or maybe a bit less, to help prevent DOS attacks.
I always thought the password should be hashed client-side. Supposedly that has some problems and it would still need to be hashed server-side as well.
So I have a proposal: client-side, hash the password. Can use any hash, although hash selection does limit the password security to its output. That hash is the new password sent over the wires to the server, that does proper password handling, but it is guaranteed a password of (say for SHA-256) 256 bits; if it receives a password that doesn't look like SHA-256 output it can automatically throw it out without even checking.
The client can then store the hash-input in his password manager, and it can be literally anything that can be thrown at the SHA hash. Is this feasible?
See http digest auth - which is considered obsolete. Mostly because it was conceived as a "more secure" way to send credentials over a clear-text channel:
The main issue with a "new" approach vis-a-vis basic etc, is that you need client support (will it work without js).
Then there's the question of what you're protecting against: if an attacker knows you accept a single round sha1-hashed pw, it's still easy to brute force through login, but it might require custom rainbow tables to account for the extra hash round.
But you'd be better off with a standard pw stretching / storage scheme for defeating off-line attacks.
not only interesting, but it is a security consideration [1]. Depending on hashing algorithm, it can take minutes to hash long passwords, so it's not just a RAM, but also a CPU issue.
This is part of why it's funny to bring up. People are so used to focusing on bozos (who store plaintext) vs the initiated (who store salted hashes) that they are taken by surprise by other dimensions.
I think it's actually 6 characters rather than 5 but yes, it's fscking terrible. It actually used to be worse, only allowing 4 characters (I'm guessing it was modeled on ATMs as they even refer to it as a "pin").
When I first read it as "PIN" I assumed it was some kind of quick password alternative for recognised devices and it would need a full password for unknown machines but nope, it's the whole password.
It horrifies me that at some point they thought, "A 4 digit pin isn't very secure, 6 should be enough!"
One more for the list of moronic password rules I experienced: no character repeated more than twice. If you have a password long enough, or a hex/base64 of a 128bit key (which I assume is safe enough!) you are most likely going to hit that limit, which does nothing to help security.
Yes though technically for a 128bit key coded in Base64 I have about 25% of occurences of a character repeated more than twice (i.e. 3 times or more). For hex, technically you can construct some 128bit where no character is repeated more than twice (but every character has to be repeated exactly twice).
Last Summer I had to create an account with HMRC in the UK. The password requirement was a minimum of 8 characters, a maximum of 12 characters, at least one letter and number, and no special characters! Quite how they came up with this set of rules has confused me ever since.
I've met several (official or less of it) instances where my default 32 character passwords are not accepted. Usually the limit is 12, 16 or even 10. My guess is it is stored as a string in a database as a fixed length char field or legacy from the time it was stored that way. Surprisingly many webshops have a 16 char limit, suggesting they use the same backend. My bank used to have 12, but now it is at least over 32 combined with some form of 2FA.
I've seen one instance where the password was "hashed" client side and the length thus didn't really matter, the implementation was lacking but they made an effort at least.
The lack of special characters is likely due to them having to work with those public accessibility terminals which have no way to enter those characters.
"Oh, and if you do happen to find a site with an odd number for the minimum length, leave a comment below because I'm kinda curious now"
Not a "web site", but Microsoft does recommend a minimum of 7 characters for Windows 10 logins, and it's the default for domain policy, so that's pretty common.
There is a historical reason why Microsoft choose 7 characters.
LAN Manager required a password up to 14 characters. It would then split the password into two 7 character parts and hash each independently. So there was no additional security offered by the algorithm for passwords over 7 characters. Today, LAN Manager passwords offer little protection as complete random tables are easily available.
Minimum password length is really only a protection against brute force attacks. And if the site in question has good protections against that (i.e rate limiting login attempts) or requires 2FA then password length could be relatively short.
Of course if the database is breached, then those protections go out the window and it comes down to the hashing algorithm used and its resistance to brute force attacks.
I think generally it will depend on the threat model of the site in question and what protections are in place.
This is the reasoning behind 4 digit pins for cards: after three wrong attempts the atm will swallow the card (which gives an average (1/10000)+(1/9999)+(1/9998) = 0.03% chance of guessing a random pin for a single card. But chances are obviously much higher if you want to guess the pin on a single card out of a batch of 10 000, or if users can pick their own pins).
I did something very similar but had the thought that making the passphrase be based on an existing word would make a good balance between security and ease of remembering without a password manager.
Of course it isn’t as strong as a purely random passphrase but hopefully it would be strong enough and still better than choosing your own password
You're partially right – it can't be the same when you're adding/setting up the account for the first time, but when you're in and things have settled down you can switch it and have it the same.
Source: me, installing a bunch of High Sierra desktops late last year.
Why can't these websites let me choose a password on my own risk? Sometimes I don't care if my account will be hacked or whatever, I just want to have a simple password. But no, they want me to create a super difficult and impossible to memorize password for my account at barbie.com.
Because (two off the top of my head) if your account is compromised in some cases it may allow misuse of the provider's resources, or even be used to attack third parties.
I was annoyed too with the password creation. Too much to think. Now I installed this addon[1] and I use a password manager to save it. I don't even know my passwords myself.
It’s a cost/staffing issue. The cost to serve password resets due to forgotten passwords is lower than the cost to respond to “My account got hax0red!” customer service requests (which usually boil down to messy identity management issues).
I've found DropBox's zxcvbn system to be ideal. Instead of requiring passwords to fit a set of arcane rules, it requires passwords to meet a threshold of entropy.
https://blog.codinghorror.com/your-password-is-too-damn-shor...
https://blog.codinghorror.com/password-rules-are-bullshit/