No, the most annoying thing is when they don't tell you the rules in advance, and you start typing a password that fits most standard rules.
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.
No, the most annoying is when you paste your password manager's auto generated long password and it silently get cut after 16 characters but successfully let you create your account. But now the login form doesn't have the same max-length property and your password will fail.
Hopefully the reset password form is synced with the login form.
There's something about pasting vs typing that fails to give the user the necessary feedback and this has been a problem for a while. I faced this same issue years ago and I finally figured out my passwords were being truncated by hitting the 'forgot password' link and noting that the service emailed me the plaintext password (another problem but let's do one at a time) which was fewer characters. My original was 32 and the one they sent was far fewer.
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.
You might be interesting in Plain Text Offenders' browser add-on. It warns when you're browsing a site that is known to store or send passwords in plain text: http://plaintextoffenders.com/
This site, while clever, is spreading potentially bad information. For instance, ive worked for plenty of companies that send out site-generated passwords. The password is stored encrypted and sent out once to the user. While not the most secure, an attacker still wont be able to get to all of the plaintext passwords if they cracked into the database.
Now this reminded me of one Unix server operated by an educational institution that shall remain unnamed, where passwords were (maybe still are?) truncated to 8 characters. Fortunately, this wasn't a problem because as long as the first 8 characters matched you could type literally anything and the password would get accepted.
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.
There is a bank which shall remain nameless (<cough>Schwab</cough>) which not only silently truncates passwords to 8 characters, but also performs a case insensitive match.
They say they're working on fixing it but it's taking an awfully long time.
Last I checked, Fidelity truncates to 10 characters, but silently converts them all to digits. They map them all to their equivalents on a typical phone keypad... so it's not even using all the digits. Talk about awful security...
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...
As long as you throttle login attempts short passwords are fine. EX: 6 digit pin on a debit card might seem useless, but if you only get 3 tries per day that's just not an issue.
~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.
I can buy that argument in general. But silently truncating is indefensible. What if I had a long password which started with my name or something, but which I believed to be secure because it had secret stuff at the end?
No, the most annoying is when you're on ios and the app doesn't integrate with password extensions and has decided to disable pasting in the password field.
Sounds so insane I guess it must have really happened.
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.
Happened to me this week. "Luckily", they also implemented the "feature" where they can send you your password by email directly after you set it, so when I couldn't get in with the password I set, I reset the password, got a mail with a new password, logged in, changed the password to a new random long string, and this timeasked them to send the password to me. The password they sent was chopped off. That told me their limit, so I could set my password a third time to get something maximally secure.
> Sounds so insane I guess it must have really happened.
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.
> Sounds so insane I guess it must have really happened.
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.
Whenever I see this maximum password length nonsense, I realize that whoever is in charge of security at this company apparently doesn't know or care about password managers. And that speaks volumes to me.
It is also a 'code smell' that suggests that the relevant company is storing passwords in plaintext.
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.
That's an interesting and plausible take on it. Why do you think new companies still go the route of not allowing special characters (like <>;"()' and the other SQL injection types)? I would think that new companies would know better by now, but I guess not?
Point is you can use passphrases that are easier for humans to remember, but you then need to measure entropy as numbers of words and size of dictionary and 16 characters is too little. https://xkcd.com/936/
Yep exactly that. It would be great if I could just use some whole words as the password for accounts which I need to use often or are really important and thus IMHO make password stores impractical (e.g. desktop login, Gmail, …)
Add second factor authorization for these, in any case. Google Authenticator app on the phone works reasonably well, or perhaps even get a physical token.
One other issue is that this indicates a site doing something they should not be. The best practice for password storage is to use a secure password hash like bcrypt, and not store the actual password at all.
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.
One startup I was working for were enforcing different rules depending on where you were setting the password e.g. 4 characters when you follow the forgotten password procedure, 8 characters when registering, 12 characters when changing password normally.
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.
I agree with the point the author is making and generally am just as annoyed by arbitrary password rules; nevertheless:
> 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
It calculates 18 quintillion years because howsecureismypassword.net is simplistic and doesn't realize english words are being used. It categorizes each character into some categories (see https://howsecureismypassword.net/assets/js/app.min.js):
// 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);
[...]
It sees the password is 22 characters long, and contains a-z chars (lowercase) and a space char (other symbols) so it estimates each char is drawn from a set of 26+19 = 45 letters. And it assumes the default bruteforcing speed is 4 billion passwords per second. So:
45**22/4e9/3600/24/365.25 = ~18 quintillion years.
It's less than that because the words were clearly not picked randomly. "Chili dog" is an English phrase, and "monkey nutso" is a transformation of "monkey nut", also an English phrase.
It's not quite like that - even if you don't try the more readily accessible combinations before the longer ones, but simply split your computational effort on each one in proportion (you'll find all of the 4 word ones have been tried when only 1/250000 of the 5 word ones have).
Not to mention that "chili dog monkey" are not exactly rare words and even a 10k word english dictionary would contain those.
And the entropy of the password 0b0 is only a single bit - if the attacker knows you've used a single-bit password. Hashed into the SHA-256 space that's only a 1:2^256 chance of someone colliding with it. Still, is that a password you'd set?
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.
What are you going on about? Your giant post did nothing to refute the point that an attacker doesn't know you are using 1 word vs 4 words vs 12.
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.
XKCD's diceware argument fails under certain conditions. Computationally very hard to crack, but when plucked from actual phrases that have been uttered; weak.
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:
Diceware proper is not 'plucked from actual phrases that have been uttered'. It's a random sequence obtained by throwing a dice a number of times (hence the name). This means you can't lookup your e-book collection for an exact phrase to use (eg. a famous quote).
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.
Yeah what I meant is that sometimes the phrase appears like natural language, and was probably uttered once, if not on a stray ebook than somebody once said it. Of course then we have have the question of whether history starts the moment it is electronically recorded.
If NLG upsets you, you can always settle for a Markov chain and some atmospheric noise to seed the random values
I'm not sure I understand how an infinite monkey attack would work against diceware.
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.
As a rule of thumb, I would go after natural language phrases first, because it is impossible to tell if the phrase was machine-generated. It's nearly impossible to arrange dots randomly on a page with a pencil because there is always some structure or engrained rigidity in human guesswork. There is also the possibility that the dots were done by 'inception', and certain biases were programmed in via subliminal messaging. Don't trust humans to do a machine's tasks.
Humans use dice to generate randomness. They throw 5 dice, to get a five digit number. They look up that number on a list to get a word. They repeat this process until they have a 7 word phrase.
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".
Rolling again, is no weakness at all. The next roll is also random and exactly as unguessable as the first. If the game was done 'without replacement' then the field would be reduced, but it isn't, and the field is unimaginably huge anyway. There is no effect whatsoever by 'rolling again' until you are happy with the result.
My buddy Tom always generates UUIDs by hitting the button several times. It gives him pleasure to 'waste' all those random numbers.
By rejecting a certain pattern you weakening the whole password scheme. It is no longer random, it is human chosen.
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.
Curious notion. So, if a guy got that "human chosen" pattern randomly, they got rooked? He has a very breakable password, while the rest of us got good ones? Sounds like the whole algorithm is busted.
100 times yes. The mere presence of a single character from a different class does not increase entropy. It means that most common passwords move from 8 lowercase letters to 6 lowercase letters plus 1 number plus 1 symbol, which is even easier to search.
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).
I don't have any real data. I know my own behavior for "sites I don't care about" and every once in a while I'm exposed to someone else's password (when they tell me their password for a site they don't care about, or where I see a password in plaintext in our shared password manager).
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.
A randomly selected member of the set of all of 8 character strings which contain at least 2 of [(upper case letter), (lower case letter), (number), or (Symbol)] has more entropy than the a randomly selected member of the set of 8 character strings which contain only lower case letters.
However, all bets are off if the respective strings are no randomly selected. 'Passw0rd' is worse than 'xmliicou'.
Third worst password rule: preventing the browser from prompting user to save the password for your site. I found this to usually happen with home banking sites (as a workaround, I usually have to disable and re-enable javascript).
That's good for browser passwords, but finding out that your 64 character password can't be pasted in the system dialog after erverything is set up is extremely frustrating (there is a hard to find command line workaround though). I think Blizzard enforces the no-paste rule in its Battle.net launcher (that you can't trick) but I'm not 100% sure.
If there is a Trojan, it can read the clipboard data. But most ppl save their password unencrypted. And can then be found by exploits in browser, java, flash, etc. Or unknowingly sharing the password file on a file-sharing network :P
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.
Why should a trojan bother to read files or clipboard data when it can read the password directly from the input field? You don't even need a trojan for this purpose, simple XSS at the right spot is sufficient. This means it's irellevant wether you write it on paper or in a file, since the password will be stolen when it's entered. The only thing you can do is to make sure your password is long enough so it can't be guessed, and that's where a password manager will help you.
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.
No. They are not superior to passwords - they merely provide different tradeoffs. For example, the site that requires your hypothetical key-type key would require that either all of their customers have spent money on such a key (bad) or that they are willing to pay for keys for all of their customers.
More importantly, you just replaced the problems of virtual keys with the problems of physical keys: you can lose them. Recovery is much more difficult than recovery of a virtual key.
With keys such as a U2F key, you can use it for multiple sites (each site will have a site-specific keypair). Most sites allow you to associate multiple U2F keys as well. Since U2F keys typically cost 7 to 15 Euro, it's really not much of a problem to buy one for use and to put one as a backup in a fire-proof safe.
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.
A lot of banks already give them away to their customers because the hardware costs are less than the fraud costs associated with compromised accounts. And in an ideal world, said keys would be general use, not just for logging into the bank's site.
Really? You don't lose (forget) virtual keys? It's a far worse problem. A physical key can always be found if you look hard enough. A virtual key can truly be lost forever.
Ok, but that makes is harder, not easier, to manage virtual keys. And the more copies, the weaker the key (the easier to find). A million is a terrible, terrible idea.
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.
Any authentication is one-to-one. The server authenticates to me, by first knowing who I am (my 'username' not a password), then using a scheme we agreed upon (our shared pair of private/public keys would be fine) to verify electronically that my machine belongs to me i.e. has the right keys.
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.
To steal a physical key you need to find a person and make him give you the key (and tell a PIN code if it is protected). It is hard to do on a large scale and you probably get beaten or go to jail soon.
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.
What about fingerprints? You don't need to buy anything, phones and such are already coming out with fingerprint readers and the technology is improving all the time. Finally, you can't lose your finger print (except in the case of extreme accidents, which exist for any type of security).
We have those keys, technically supported in every browser, and you can decide on the level of security that you want - and store keys on highly secure tamper-resistant hardware tokens or manage everything purely in software of your choice.
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.
U2F works too, and it even hides the details about which sites you have registered in from everybody but each individual site owner - you can't identify the individual token of know if your users have registered elsewhere or not even if you compare account details. They use unique keypairs for every site.
As far as I get it (I haven't read much about U2F), U2F is generally perceived - and advertised - as a second factor, not the primary credential like a password.
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.
Ironically, it's easier for me to log into my internet banking than twitter because internet banking only has a hardware key and a simple 6 digit pin, but for Twitter, I have to go find my paper password list and type it in. It would be great if there was some kind of common hardware key that could be used on multiple sites.
Hey that looks fantastic. It only seems to be supported by about half a dozen sites though. I wonder if there are some big costs to a site adopting it.
The protocol is open, the libraries for implementing it are too. You just have to look into how it works and differ from what you have, and integrate it correctly into your auth system.
No doubt a lot of people suck at password management, but with proper management it's easier for a thief to steal a hardware key.
Or a phone. Which is why I hate that some new services require a phone number for authentication.
I don't think so. Stealing passwords from password manager with a trojan software is much easier (and safer) than breaking into somebody's house. In some countries you can even get shot for that.
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.
> 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.
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.
I like the happy medium of one ultra quantum unbreakable master passphrase which is used to unlock easier to guess passwords. SO somebody owned your Imgur account full of memes. So what? Always assume an account is breakable.
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.
Hardware might be a nicer UX (though god forbid you forget your dongle one day and are completely screwed). But I fail to see how it's more secure without a second form of authentication.
I was in Chicago with my family recently and purchased a one-day pass for the CTA. When I returned home I found you could create an online account connected to the card, ostensibly to be able to fill it up automatically, but also to track your ridership. I thought it would be interesting to see what kind of data a rider could get from the card.
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.
Last I knew, the T-Mobile registration form prevented typing the letter 'v' in the password field. It was a rookie programmer trying to prevent pasting.
Totally agree.
At least 1 Uppercase means 99% of people just use an uppercase first character for their standard password. 1 number means they append 1,2 or a year and 1 special character means they append an exclamation mark. Entropy added = 0 (if password rules are known to the attacker). I don't get how anyone who cared the slightest about security would think otherwise and enforces these stupid rules.
I think a lot of it is driven by management. I've had to talk management out of it before. Then they still "don't get it" and think I'm OK with an "easier to hack" website, holding it against me as a character flaw - as if I'm a bad engineer who doesn't believe in diligence.
Anyway, that's probably where they come from - implemented by more obedient employees.
I see this a lot now, with the proliferation of libraries that allow for arbitrary passwords. Possibly some form of systemic trickling down of bad practices into software with horrible consequences
"Your password must contain the seventh circle of hell, and a Taco Emoji"
Out of all, my bank forces to have my password to have exactly 5 chars. This is madness. Fortunately to actually do anything I need a second authentication factor.
I despise expiring passwords. My university makes me change my password every 6 months, and they keep a list of the last 2 year's worth of passwords so that you can't reuse them. That, and they disallow some characters such as "#" and " " (space). It's annoying.
I don't care for them either, but there is definitely a purpose: it limits the vulnerability period of a users password compromise.
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.
They also did that at one of my previous workplace. We couldn't reuse any of the passwords we used in the past (no limit apparently), but in the form to change our password, they checked if the current and new passwords were different w/ some Js.
With the help of firebug we could keep the same password as long as we wanted.
I use pwsafe for iOS (yes trusting some guy built a binary ok) to keep my many passwords for each domain. It will generate (no I don't know the RNG) passwords based on policy settings (length, characters, etc)
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.
Often the stupidest limitations in passwords come from the backend system being an ancient banking/insurance/healthcare system running on a mainframe using rules that were prevalent 30-40 years ago. Having worked for a smallish financial/banking company we had an AS/400 with code mostly written in a 4GL tool as the system of record. The database didn't even have unique keys. Everything modern (like web apps) was limited by what this system supported.
> "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.
It always seems like banks are way behind the curve on this for whatever reason. My old credit union that I left a couple years back required specifically a 6 character ^[0-9]$ password for complete access to my account. I have no idea why this seemed like a good idea to them. Plus the idiotic security question crap that they usually store in plain text. Just let me store my email and send me an email if I lose access; security questions make you /less/ secure.
I've been wondering about password complexity for a while now. If a password is cryptographically hashed, so long as it isn't a dictionary word or date, why on earth do people add in complexity rules that prevent arbitrary character sequences?
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?
It forces people to use Password1# rather than just password. There are many, many more people with an easily guessable password than there are with entirely random 8 char passwords.
Well, if you put in xuui-659995!?)) then it won't let you use this either. How does that make any sense?
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?
For most websites, users should just be warned that their password is insecure, not forced to use a stronger one. Your website probably isn't important enough to me to get its own strong password.
I would also add to this statement that this shouldn't be user's problem, but service problem.
By forcing setting strange passwords services transfer their problem to secure passwords to user's shoulders.
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.
Instead of that I can see the opposite practice: service set draconian password politics, but just allow requests with incorrect credentials without any limits: "30req/sec? You're welcome, buddy! Need an API maybe?"
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!"
These surprises are up to every developer's/another genius infosec imagination :)
So, my conclusion is that best security systems should be almost invisible to normal users and let attackers screaming.
Truncation: The browser could have warned users for years already. Pasting something that gets cut off is data loss. Relying on a JavaScript implementation to do this is a hack that only covers some sites (yes, you could have an add-on, but no, that would require JavaScript, and it's still a hack).
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?
I was disappointed to learn that Android wouldn't accept a password with non-ASCII characters. I wanted to mix accents, punctuation, and symbols that are all easily typed with the soft keyboard, but it was rejected as "too short" because anything that wasn't between 0x20-0x7E was trimmed.
Apologies if this is a common held practice which i'm unaware, but why not establish a policy amounting to: "if the system-admin can't somewhat trivially crack your password then i won't bug you about it". That is, allow any password, then if your chosen crack software can't crack that password, leave them alone. If you can crack it then: "Please select another password, as our trivial cracking software discovered it". This would strike me as a less user burdensome method which would be more generally secure than every 13 weeks: "9-12 characters including one of each of the following set"
Allowing 100,000 login attempts per second is in itself insecure! Using longer passwords in that case is just treating the symptoms of a bad security strategy.
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.
I was looking for a cloud MongoDB provider, so I found MongoLab then I tried to register. It didn't let me because my password didn't have a number in it, do you want to know the password I used? Here's the password:
U\"&%x#vdE
Their support site has more ridiculous password rules. Like one capitalized letter, one number, one lowercase letter, one non-alphanumeric, etc.
I asked the support and he said this:
Not all of our users are as savvy with security concerns.
I told them Google allows "aaaaaaab"...
I wish them to get rich with their non-savvy users, best of luck to them.
"Through 20 years of effort, we've successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess." Wow.
Combination of words are the way to go. Often, when I tell people that, they seem to get stuck probably because that's not what they've been used to doing. I would be inclined to give some kind of hint to the user: "a good password, easy to remember: pick at least 4 random words and separate them by a character of your choice."
Password rules are needed, otherwise passwords would be even worse than they are now, with people going back to using '1' or '1234'. They just need to be better designed:
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
The worse ones are the constraints to which characters one isn't suppose to use, which on my book only reveals sloppy coding as the developer wasn't able to cope with arbitrary characters.
Sometimes it reveals things about the underlying system (e.g., that they are storing passwords on a mainframe, or in a database with a different character set).
The iCloud and Microsoft account password rules are bad examples. The first one forces one to use certain characters (uppercases, numbers) amd the second one supports only up to 16 characters.
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.
Can you explain why the XKCD scheme is weak to dictionary attacks?
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.
Of course, it's not the worst schema. But it gets a lot more credit than it is worth.
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.
> especially given people tend to use common words
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.
> Except, how can you be sure your password was stored securely? You should never assume that.
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.
> 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 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.
Absolutely, use something different and more complex to 4 common words. That's pretty much what I am saying. My argument is that whilst you are switched on to the problem enough to do that, a lot of people simply are not. So stuff like the XKCD comic can be harmful.
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.
No. For a dictionary attack, someone would need to know that you are using words. They would need to know if they are separated by spaces, or dots or slashes. The probability of someone knowing your personal scheme is fantastically low, unless they already know one of your other passwords and can guess it. A password like:
"Żółć 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$#^@%$@#$#
By people who knew to look for obscure african poems? I mean sure, you could guess a Polish sentence if you used a Polish dictionary, but how likely is that?
I'd probably sacrifice my firstborn if Microsoft would finally wake up and accept passwords longer than 16 goddamn characters...