Stop forcing arbitrary password rules
ryanwinchester.ca
ryanwinchester.ca
I'd probably sacrifice my firstborn if Microsoft would finally wake up and accept passwords longer than 16 goddamn characters...
If one actually does this, the length of the password becomes almost irrelevant to the server. You might want to reject 10MB passwords or something, to prevent someone from taking up all your RAM during login, but the difference between 16 characters and 1024 (or 72, the max for bcrypt) is irrelevant.
Now either you get through but don't know if you could've used a better password. Or your password will be denied and you have to make adaptions or change completely.
Hopefully the reset password form is synced with the login form.
I had similar issue with paypal once. Their bank account number field expected to get N digits without spaces, so it was hard limited to N characters. Of course they didn't bother telling about that. When I pasted my number with some K space separators tossed between digits, the last K digits have been silently truncated. Boom, account locked.
That happened to me on either "verified by visa" or the mastercard equivalent. I had to reset my password a few times before I figured that one out. For those that haven't used this it's an extra password protected step that comes up sometimes when purchasing things with your card.
I had it happen to me when changing a password on an Apple ID account 1-2 years ago. My password was accepted without an error and truncated to 32 characters.
Well at least Microsoft stopped doing that and are now displaying a message that the password is too long instead of doing it silently.
I emailed support to ask and they said 'oh yes, we limit the number of characters in your password'. There was no documentation or feedback on the page to tell you this if you pasted the password, but if after pasting you deleted the last character and then tried to re-type it, you would see the error. Pasting never triggered the tooltip telling you the issue.
Now I try this each time I sign up for something which is a minor hassle but still much easier than the seemingly random failures I had been seeing. It also taught me to immediately sign out and test the services' password recovery functionality to weed out the ones storing plaintext passwords, so that's good.
Funnily, the admins apparently really cared about security very much, so they required users to change passwords every few months. It was possible to change asdfghjk to asdfghjkl and keep logging in with asdfghjk. I kid you not.
They say they're working on fixing it but it's taking an awfully long time.
~10-20 failed attempts per day per IP + some rules to check for multiple IP's per account and 8 lowercase letters - most common passwords is actually reasonable.
Not if the password-hash database leaks.
Edit to add: It appears they may have fixed this misfeature. I did personally verify that you could log into their website with the phone-equivalent digits at one point, maybe a year or two ago. There's also a few forum threads about it around the net, eg https://www.bogleheads.org/forum/viewtopic.php?t=93792#p1350...
Secret question: what was the name of your first born?
Reason: If they were hashing the password, the hash output would be fixed length, independent of the input length, so there would be no need for an external, user visible, maximum length restrictions.
Another thing, a visa broker in Turkey had a so ridiculous password rule and gibberish error message, I had to read the source code and parse the regex by hand. Only then I was able to type in a valid password.
> chili dog monkey nutso
Is definitely not 18 quintillion years at best it's approximately 250000^4 which is 2^72.
A good (though still requiring some memorizing effort approach) would be something along the lines of https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi... which uses a standard dictionary of 1626 easily memorable english words with each password being a 12 word mnemonic phrase. 1626^12 ~= 12^128
If the attacker knows you've used four dictionary words in a row. Now you need to multiply the number by the odds of that..
Not to mention that "chili dog monkey" are not exactly rare words and even a 10k word english dictionary would contain those.
What does that have to do with the output of the password in terms of brute-force guessing? Aren't you kind of assuming that an opponent won't try a broad dictionary attack? Equal distribution of hash outputs fundamentally assumes equivalent distributions of hash inputs, and that's not true for the distributions of common passwords.
Again - everyone knows the passphrase patterns everyone uses, everyone knows the password transformations everyone follows (eg l33t) and overall those patterns are significantly weak against attack because of this public knowledge. By those algorithm, with knowledge of salts/etc those passwords are very weak.
Should you use a song, or a slight modification, or a l33t transformation? Certainly not - if the input space isn't uniformly distributed across the input space, the probability of hitting pay dirt definitely isn't uniformly distributed across the output space.
Even the class of "valid transformations of sensical English sentences" is not an equal distribution because of the above. If you can compress a language you can attack it, because by the assumption of compression the data is not at its minimum entropy. Maybe not feasibly if you're lucky - but don't bet on it just because Webster's is big.
Also, you seem to imply that there is a distinguishable difference in sha1 outputs of good random inputs and English word inputs, which violates a security property of cryptographic hashes. So there is a lot of fame to be had if you can prove that.
So to give an example, any natural language phrase like:
"I took a walk in a park" is easier to crack.
I am certain there is somebody coding an infinite-monkey-type bruter to crack diceware as we speak:
Let's assume a word list of 7776 words. All words are lower case alpha. The attacker has pur wordlist. And the attacker knows there are seven words in the passphrase.
That's still 7776^7.
Even if we prune the wordlist ("I'm not using 'zerg' in my phrase", "I rolled 11111, that's not random so I'll roll again") it's still not an attackable space.
So, there are weaknesses if humans roll the 5 dice and get 1, 1, 1, 1, 1 and then say "That's not random, I'll roll again"[1] or they roll a number, look it up and say "I'll never remember 'zerg', I'll roll again".
My buddy Tom always generates UUIDs by hitting the button several times. It gives him pleasure to 'waste' all those random numbers.
When someone rolls 1,1,1,1,1 and rejects that word they've cut down the word list to 7775 words. That's tiny, but it is a change.
An attacker can under certain circumstances exploit this behavior. For example, if they notice you are picking shorter words or words that consist of certain characters, they will have an easier time to crack the password. Whole categories or patterns can be rejected because of that, reducing the search space.
An extreme version of your method, is picking only the patterns that relate exclusively to you, like picking your favorite music or hobbies. Then the whole scheme becomes useless.
Moreover, diceware can be set up with any dictionary, and nobody stops you from computing your own dictionary. If you do that, good luck to the bruter attempting to break your passphrase!
BTW there is no limit on the number of terms in your diceware passphrase, so if/when brute force makes 5-term phrases too weak, users may just add one or two more terms.
If NLG upsets you, you can always settle for a Markov chain and some atmospheric noise to seed the random values
// Standard ASCII Characters
add('ASCII Lowercase', /[a-z]/, 26);
add('ASCII Uppercase', /[A-Z]/, 26);
add('ASCII Numbers', /\d/, 10);
add('ASCII Top Row Symbols', /[!@£#\$%\^&\*\(\)\-_=\+]/, 15);
add('ASCII Other Symbols', /[\?\/\.>\,<`~\\|"';:\]\}\[\{\s]/, 19);
[...]
45**22/4e9/3600/24/365.25 = ~18 quintillion years.If you have a sophisticated entropy estimation tool, or library, great. Another simple thing is using a min length, plus restrict from a dictionary of the million most leaked passwords to outlaw those (can hold it in a bloom filter if size is a concern).
It means that humans reduce the entropy across the board to (more than, IMO) compensate for the mathematical advantage.
There's an awful lot of "capitalize the first letter" and "replace e by 3, a by 4, o by 0" and "sometimes append a bang". That results in meeting the password complexity rules without any additional entropy in the first 2 rules and 1 bit of entropy for the last rule.
However, all bets are off if the respective strings are no randomly selected. 'Passw0rd' is worse than 'xmliicou'.
As seen at The OS X FileVault dialog, PayPal, Blizzard and many more....
1. Right-click the field, Inspect element.
2. Go to Console tab, type: $0.value = 'mypassword';
$0 is the last selected element: https://developer.chrome.com/devtools/docs/commandline-api
1. click on the input field. 2. Type document.activeElement.value = 'MyPassword'; into the console.
javascript:(function(){var IN,F;IN=document.getElementsByTagName('input');for(var i=0;i<IN.length;i ){F=IN[i];if(F.type.toLowerCase()=='password'){try{F.type='text'}catch(r){var n,Fa;n=document.createElement('input');Fa=F.attributes;for(var ii=0;ii<Fa.length;ii ){var k,knn,knv;k=Fa[ii];knn=k.nodeName;knv=k.nodeValue;if(knn.toLowerCase()!='type'){if(knn!='height'&&knn!='width'&!!knv)n[knn]=knv}};F.parentNode.replaceChild(n,F)}}}})()Browsers should probably not allow that kind of interaction between javascript and the password field.
It's more secure to write it down on a piece of paper, then saving it on your hdd and copy/paste into the password box.
Passwords are awful UX design solution. The users have to think of and remember some meaningless phrase to get the service they really needed. If you use easy password, your account can be hacked. If you use difficult password, you won't remember it in a week.
For some people remembering a password or login might be especially difficult.
You can use software to generate and remember passwords but all of them will be lost if you reformat your drive. Some of password managers are proprietary, non cross-platform and some would upload your passwords to the so called cloud so NSA can look at them too.
In any case your passwords can be easily compromised when your PC is infected or you use somebody's else device.
What we need is to get rid of this obsolete system. We need hardware authorisation key (that could look like a real key) that can be used for both registration and logging in and would generate and securely store private keys for all used services. Such device should use strong crypto, should not allow exporting private keys, update firmware or operate without user confirmation.
I think such kind of keys will appear sooner or later, they are superior to passwords and password managers and easy to use but I am not sure that they will be open source, cross platform, and backdoor-free unless we do something in advance.
This is something that has been thought about in detail - see https://vtllf.org/blog/ssh-web-sign-in/quest-to-replace-pass... for Stajano's analysis.
That said, I think it's bad to rely on one factor. If the key gets stolen, security is compromised. The combination of a password and a security token is far more secure. People should just stop memorizing passwords for every site and e.g. use a password manager.
And passwords can be stolen remotely using trojan software. You won't even know whether your password was compromized.
I agree the recovery can be a problem but there probably are ways to solve it.
Sure, but it's super easy to make backups of virtual keys. It's a digital file - just copy it.
Worried one backup isn't enough? Make a million. Space is cheap.
No, I despise passwords. The whole scheme is backwards. I don't want to authenticate myself to the server; I want to authenticate the server to me. Why doesn't it provide the password, and my computer verify it? Why is a fallible human being in this game at all?
Well, yeah. That was a hyperbole. I didn't actually mean that you should go out and make a million copies of your key.
It simply meant to show that it's easier to prevent the loss of a virtual key than it is to prevent the loss of the physical key.
> The whole scheme is backwards. I don't want to authenticate myself to the server; I want to authenticate the server to me.
That's... interesting. My first thought when I read that is that the server is the one with your data and multiple users - so it needs to authenticate you to make sure that you only access your data and don't gain access to other users' data.
A server authenticating itself with you would tell you that you're actually talking to XYZ and not an imposter, but once that authentication took place you'd have access to everything on that server. Including other users' data.
How do you imagine this working?
So we are both authenticated to one another. Except now, we're using sophisticated passwords and Digital Computer Logic to work them out. Instead of my fallible wetware.
But, sadly, it's not usable. See my reply to grandparent comment.
You can't lose your fingerprint, but you can't replace it either - so what happens when somebody clones it?
http://www.theguardian.com/technology/2015/sep/11/gchq-passw...
It's called TLS client certificates and no one supports those.
Browser vendors make UIs that are absolutely awful (it's like they do this on some damned purpose!), there is no synchronization for low-security software tokens (yup, it's not a big deal to sync some private keys in a same way we sync other credentials like passwords), standardizing organizations don't work on multiple signatures (say, gradually ditching X.509 in favor of OpenPGP - TLS doesn't really care how blobs are encoded). So, the sites don't consume them, although technically everything's there - a <keygen> element, JS APIs, TLS, anything.
On the other side, client certificates (be it TLS with X.509 or whatever) are generally considered as password replacements.
I mean, I suppose many don't want a password - just click an identity with autonomous credentials that don't depend on any third party, optionally do the confirmation ritual (hardware button, PIN entry) - and get recognized.
You can say the same about credit cards: they can easily be lost, stolen etc. But generally they are better protected than internet bank account with just a password.
And the most appealing point is ease of use. Inserting a key and pressing a button is much easier for a common person than dealing with complicated matters like login, email or password.
I've physically lost one credit card and had multiple ones canceled unilaterally by the bank because some idiot merchant got hacked. On the other hand (afaik) I've never lost any bitcoin or any bank logins/passwords that were fully under my control.
It wouldn't be as secure as a special purpose device, but it would be a whole lot more convenient. Given that people are using banking and pay apps on their phones, I think it doesn't really introduce any new issues for the typical user.
But using bank application on a phone is totally unsecure. A modern phone is a computer with complicated software that can be exploited.
I spent quite a bit of time trying to create an account only to receive a generic 50x error page each time. I tried disabling adblockers, completely unblocking javascript, disabling extensions, and nothing worked. I tried it in different browsers, and on different computers. I still received the 50x error. Then, on a whim, I tried using a different password. When that worked, I tried changing the password using 1-character-removed tweaks of the original. There was a single character that, it turns out, would cause the application to choke on passwords (I don't remember which character). Presumably it was an escape character or a semicolon.
It's not impossible for account systems to fail in unexpected ways, so there are probably more than a few (poorly-designed) websites which have seemingly arbitrary password requirements which are designed to avoid the kind of error I found above. Still, it would be better to fix the error in the webapp than to try to patch it by limiting the user input - that's an obvious security problem waiting to happen.
Anyway, that's probably where they come from - implemented by more obedient employees.
"Your password must contain the seventh circle of hell, and a Taco Emoji"
With the help of firebug we could keep the same password as long as we wanted.
For example, if you share passwords between sites, compromising one site gives you a limited time frame in which to attack the other. 6 months isn't even a bad compromise; some places with high security requirements make it 30 days.
And like the author, flat out my number one bugbear is that no matter what random(ish) password I choose before signing up, some idiot will decide that my 12 letter password is too long or my password must have an upper case, or a number of a special character - but never in a consistent manner.
I really want to just move to google authenticator and one factor auth. Just stick a QR code up, let me photo it on screen and I will give you a HMAC code right back.
No passwords. Just illusion
> "Schwab.com passwords are limited to eight characters, cannot contain symbols, and are case insensitive. " > "I now know that on the backend, my secure 16 digit password got stored in the system as only the first eight characters." > "So what they do is allow UP TO eight characters to represent the password, which is stripped from the contents of the password field. Assuming that the user is activating a token, there will be characters left over. Instead of using the LAST six characters to check the token code, they pull the NEXT 6 characters."
Seems like these companies just do not want to put the effort or deal with the customer pain of updating to a newer model.
What I'm getting at here is that if you had a 8 character password (for the sake of the example), and you can type in lowercase letters, uppercase letters, numbers and punctuation marks the total combinations of values is 95^8.
But then you remove all possible values of just numbers, all values that are just letters, all values that are just special characters. That reduces the set of combinations by (52^8) for alphabetic characters, then reduce further by 10^8 for numeric only values, then 33^8 for special characters. That's quite a few characters removed!
But then you get Apple's recent password requirement of no repeated characters in their iCloud and App Store passwords. My math behind permutations is a bit rusty, but that removes a hell of a lot of passwords as well.
On top of this, if you require at least one special character, alphanumeric character, and at least one number, then that reduces the number of possible passwords even further!
I've never understood how this made passwords safer... What am I missing?
Edit: In fact, interestingly I used a pseudo-"random" generator made up in my brain. And there you have a big problem - I couldn't help myself but I grouped letters, numbers and special characters.
I have to ask - if most of us do this, as we pick our own passwords, then don't we by our very nature make it easier to crack our own passwords?
Instead of following shitty password rules in forms, it's better to make it very hard or expensive to brute-force these passwords. So any heuristics to identify ubnormal/dangerous activity and take an action by decreasing attacker chances like rate limiting/captchas and so on.
* If you see one IP trying to login with incorrect creds with really high rate - then it's probably attack.
* If you see really lots of IPs trying to crack specific user account at the same time - then it's probably attack.
I can suspect something like this happened before:
"It looks like a lot of work with rate limiting and all the stuff, let's just force our users to set 10+ character passwords with one+ capital letter, one+ number, one+ special character". Oh, and in these examples there is usually cherry on cake like:
- Dev1: "Let's not allow 2 same characters or 3 characters of same type"
- Dev2: "Let's also force our users to change their passwords every 3 months"
- CEO: "Brilliant ideas! We're secure now!"
So, my conclusion is that best security systems should be almost invisible to normal users and let attackers screaming.
Binary Passwords: I could just copy/paste blocks of hexadecimal digits into the password field using a fixed number of digits corresponding with the key size, and they would be interpreted as a stream of unsigned binary octets. The only thing you'd need to know was the length.
A suitable format is using hexadecimal. If you're using a password manager, you already don't care about what the characters are, only that it is secure.
Passwords are also no longer limited to use printable characters.
How would you implement that for all users? Adding a prefix like 0x to enter hex mode?
Good security strategy: Have many layers of security! For example: Limit the login attempts to max ten tries. And another layer, whether you like it or not is to make users not use their "standard" password.
More security layers: hash+random salt, SSL, password timing, logging, 2-way authentication, hiding, white-listing, ... a strong password =)
Please note the difference between cryptography and password authentication though. In cryptography, a longer key is most likely always better.
U\"&%x#vdE
I asked the support and he said this:
Not all of our users are as savvy with security concerns.
I wish them to get rich with their non-savvy users, best of luck to them.
Must have at least 16 chars, OR Must have at least 8 chars with 1 number, 1 letter, 1 symbol, AND Must not have more than 3 repeating characters
Stuff like "I like spaces" would not work.
The "4 common words" password meme was around a lot after that comic. However, such passwords are definitely not secure because a good dictionary attack will break it in hours. You do not have as much entropy as you think with them.
The same problem tangentially applies to his suggested password schema to.
The problem is: as soon as you start using human word or pseudo words then your complexity decreases significantly.
With that said he has a point: password complexity schemas as employed by websites are not good enough. It should enforce length and complexity properly (not by saying "you must have these types of characters" but by really analysing the password).
I appreciate the UX problems involved there... but then we could push people towards using password managers and auto-generated passwords.
Summary: use a password manager and auto-generate complex passwords.
Using the 2048 common words example from the comic, there would be 2048^4 = 1.8e13 four word combinations. I don't see any possible attack that's faster than brute-force here.
Using dictionary words reduces the entropy of your password significantly. And for a cracker it can be trivial to attack passwords of that form. Given the sort of compute power you can obtain cheaply nowadays, attacking 4-word schemas (especially given people tend to use common words) is not hard.
It's to some degree security through obscurity: no, a cracker will not know your schema in advance but he will attempt to attack multiple schema types. If you're the sole target then that's probably not a concern - it would be a major effort, with limited rewards, to attack your unknown password schema. But if yours forms part of a larger set of passwords being attacked (where the use of multiple schemas and attacks will reap high rewards) then you're at more risk.
IMO, for all the password schemes that people come up with there is no good alternative to a long, randomly generated string with multiple character types.
Always use a password manager!
You don't pick the words yourself, you choose them at random. That's the whole point.
> Given the sort of compute power you can obtain cheaply nowadays, attacking 4-word schemas (especially given people tend to use common words) is not hard.
If the password is hashed with bcrypt with a work factor of 10 (the default in Rails), it would take ~5500 years to crack a single xkcd-style password on a single modern CPU core. Maybe 4 words aren't enough to protect you from the NSA, but they're enough to protect you from Joe Botnet and his db dump.
> You don't pick the words yourself, you choose them at random. That's the whole point.
Suggest: you're supposed to choose them at random. In practice (source: 5 years as a security analyst) this does not happen. People are predictable!
You don't have to. You can use a password manager with an open protocol (like 1Password) where you can tell the db is encrypted using a key correctly and slowly derived from your master xkcd-style password.
If done correctly, it's a much better scheme than randomly generated characters because at the same level of entropy you wind up with a password you can actually remember and type quickly and use consistently in conjunction with a password manager.
If you put it like that, then passwords are security through obscurity too, since they are only secure because the attacker does not know the password? It's really all about having your own, personal schema. Even a slight variation of a popular one will put you safely out of the path of that multi-schema dragnet if the resulting password isn't part of any of the schema spaces. Just make sure it really is your very own variant and not something many others would also come up with. Add a part of that old line noise password you still remember from university at a fixed position of the word list or something like that. Even a recycled ATM PIN might help, your word list just got 9999 words longer. Add those digits to the individual words? 9999 new dictionary schemas to process. To play on the old Clarke: any sufficiently high number of possible password schema variations is indistinguishable form requiring a true brute force attack.
> Always use a password manager!
Yay, a single, juicy target, synchronized to any number of devices of various levels of tamper resistance, maybe even with some user-friendly automation that will happily hand out login pairs to anything that has temporarily taken control of your browser. With local exploits empowered by such a big sign saying "this is where the good stuff is kept", do you know a good writeup of practical password manager risk mitigation strategies? Like adding a brain-stored suffix to the more important ones and so on, so that an attack script would also need to do key logging or mild individual brute forcing. I'm sure there must be an established body of expert opinion on this somewhere.
To the second part of your post: sure it's a concern. But that wasn't really the subject of the post. You will never protect yourself completely, but I've always argued that if you're concerned about the sort of things you're concerned about it's already too late. We should train people to use the internet safely and be alert for compromise at the individual level.
"Żółć zżółkła w gąszczu fantazyji!"
Is absolutely impossible to crack in any reasonable amount of time. It's a perfectly valid sentence in Polish, but the attacker would need to know to use a Polish dictionary, and also a one of these words is an old-Polish word which will not appear in any modern dictionaries. Finally, they would need to know you have an exclamation mark at the end.
It's literally impossible for someone to guess all of that, and this password is infinitely easier to remember than !@#%#$@j4jnvdbst$#^@%$@#$#
Once a single one of those is hacked your method is exposed and it goes from improbable to practical.
No, an attacker will not know your schema. But she will know all about the common schemas. And you're risking her using your schema in her attacks.
Your proposed password is much better than the one XKCD's proposes because you're using uncommon words and punctuation. And I agree, it's more secure.