Your Passwords Don't Suck — It's Your Policies 487
First time accepted submitter eGuy writes "ZDNet sparked a debate about password policies when John Fontana wrote about my open source (LGPL) password policy project that rewards XKCD-like passwords. Steve Watts of SecurEnvoy replies that it is too little, too late. What think ye? Is there hope for passwords?"
Wrong (Score:3, Insightful)
The trouble with the pass phrase concept is that the whole words just become tokens. Most people's vocabulary is not that large. You could use a common spelling dictionary and toss in the like substitutions 0 for o excetra and you don't really have a key space much larger than normal 7 character or so passwords offer
Terrible password policies (Score:5, Insightful)
The main problem is... (Score:5, Insightful)
My bank's website enforces a MAXIMUM length. I'd love to have a password like "c0rr3c7 h0r53 b4773ry st4p13", but I can't use more than 6 characters.
Yes, you read that right. 6 characters. Maximum.
I fear for my online bank info constantly
Why would there ever be a reason to enforce such a small maximum length? I don't get it.
Re:This is too simple to fix (Score:5, Insightful)
because it would take longer to type
I disagree, my ability to type words in sequence each day has made me quite efficient at doing so, a garbled string on the other hand I am not. The lowercase, uppercase, numbers and symbols make passwords longer to type.
With different passwords for each site (or at least each serious one such as banks) the garbled text approach is very inappropriate.
As passwords are stored in as a hash created with a salt the password is always stored as a fixed value (128bit for MD5 etc) it requires no additional storage for the servers/databases.
Re:XKCD (Score:3, Insightful)
The problem I have with that comic is that the "strong" password is lowercase only.
Sure, its 28 characters, but its still lowercase only.
That makes it a lot weaker, no? I personally use a 17 character long password (for anything important) at this time, being somewhat random and including lowercase, uppercase, numbers and special characters. If there is one thing I have seen from hashtables, its that adding in special characters makes it a lot harder, and sometimes outside the realm of possible.
Never mind that if you know the person is using special characters, you still gonna have a lot longer time cracking, if you know he is only using words, with the help of dictionary attacks you gonna run through them a lot faster.
Oh, and the way I manage to remember my long password is that I take the short, I assume random, passwords that I have been forced to remember for a few years, like for school, and add those together with a special character in between. Makes it very doable to remember.
I think the point is that even with all lower case, it's still "good enough" and far better than a shorter password. Mixed case (assuming you capitalize the first letter of each word to keep it easy to remember) only adds one bit of entropy.
My problem with the xkcd scheme is that users are lazy and rather than pick 4 random words, they'll pick 4 words that are easy to remember in sequence: "haveityourway" "darksideofthemoon" "thesearenothtedroidsyourelookingfor", so with a phrase dictionary and some grammar rules, you still have a good chance at brute-forcing some user's passwords.
Wow... (Score:5, Insightful)
Congratulations on winning the Slashdot trifecta - you managed to invoke the GPL, cite XKCD, and slashvertise your own project all in one!
Re:The main problem is... (Score:5, Insightful)
> I fear for my online bank info constantly .
And yet you continue to deal with that bank. Why?
Re:XKCD (Score:5, Insightful)
My problem with the xkcd scheme is that users are lazy and rather than pick 4 random words, they'll pick 4 words that are easy to remember in sequence: "haveityourway" "darksideofthemoon" "thesearenothtedroidsyourelookingfor", so with a phrase dictionary and some grammar rules, you still have a good chance at brute-forcing some user's passwords.
You could perform this attack using Google's autocompletion database as a dictionary.
Re:Passwords DO suck (Score:5, Insightful)
All digital security boils down to the key sharing problem.
And the key sharing problem is "solved" in practice thusly:
Server: O hai! Give me your infos! Here's my certificate.
Computer: Warning! This certificate is not trusted!
User: Ignore warning, add certificate.
Computer: K.
OR
Server: O hai! Give me your infos! Here's my certificate.
Computer: This certificate is trusted because VeriSign totally vouches for these guys.
User: VeriSign?
Computer: Yeah yeah, we totally trust VeriSign. I mean, we've never met them, we don't know their policies, and we rely on VeriSign to tell us if their shit gets stolen, and we basically have no recourse if shit goes wrong, but we trust them.
User: K.
Nobody ever actually checks to see if something is legit because they want it to be painless and automatic. I'd love to be able to go to bank.com and view the certificate, then call the number on my credit card (or go in to an actual bank location) and see if the certificate matches up.
Re:Wrong (Score:5, Insightful)
That's why you use a standardized list of tokens (mostly words, but some non-word tokens as well) such as Diceware [std.com]. With 7776 tokens, the keyspace is far larger than the "normal 7 character" password. The trick is to ensure that you are choosing the tokens randomly. You can use dice, your favorite random number generator [random.org], etc. I use several 4- and 5-token passphrases that I have remembered literally for years, each one unique. Type them enough times, and muscle memory takes care of the rest. Even after a period of non-use, it amazes me how my fingers will remember the passphrase but yet I can't recall the passphrase itself.
Re:The main problem is... (Score:3, Insightful)
As someone with a rather embarassingly similar system to support, I can sympathize with your concern. We railed against the limitations of the software vendor when we switched to it, but their attempts to fix it caused new issues. At first we had a system that truncated the longer passwords our users had on the old system, and then later when they tried to expand the length of input, those users with longer passwords they'd been transparently using were suddenly getting told their password was incorrect because the stored truncated version didn't match the longer version they were typing in.
As an example the password "iLikeLongPassword$ican'tT3ll@Lie" was stored internally as "iLikeLongP" and happily accepted, but the new password "iLikeLongP@sswordsButChangeWhenIrritated" was treated as a duplicate. When they implemented a fix, it started comparing "iLikeLongP" to "iLikeLongPassword$" and gave an authentication error. To prevent the overlap, they limited new password entries to ten (example only, not necessarily reality) and users were rightfully indignant thinking (incorrectly) their older password had been more secure.
Rather than have the system recognize truncated versions of the same password and prompt the user that the system had been updated and their longer password was now stored, they rolled back the "fix" to the older more limited system.
What they should have done was update the system to read the full password entered by the end user, and submit that to the authentication system, and if it failed, submit the truncated password to the authentication system. If the truncated version matched, it should have then alerted the user that it was now storing the fully complex password and then updated the stored version.
Why? is what you asked though. The short answer is that it probably relies on backend systems that were historically much more limited and weren't designed with modern security issues in mind. In some cases the password storage was designed to be able to be decrypted, in others the database was designed with a specific length for that entry. "Why don't they fix it" is the obvious followup question, but the answer is long [slashdot.org] so I won't repeat it here for the sake of brevity.
Re:This is too simple to fix (Score:5, Insightful)
we widely distribute a standard library method for computing password entropy and let people pick what kind of strong password they want to remember
There are a few complications with this.
1) Humans are incapable of picking entropic passwords. They think they can, but they can't. So the measure we need isn't actually one of entropy, though it looks like that to computers.
2) Mostly due to (1) above, computers are incapable of correctly calculating the entropy of a human generated password. They can calculate the entropy of a string of characters if they presuppose that the string of characters was not generated by a human.
3) Even if we assume that humans can create entropic passwords, it's difficult for a human to estimate that entropy. What happens when the password entropy checker rejects "This shit tastes like chicken"? How does the human know how to make that password more acceptable? Is "shit this tastes like chicken" any better? How about "chicken like this tastes shit"? Or "Tastes chicken shit this like"? How does that even compare to a shorter string of letters, numbers, and symbols which don't form a word? To the person behind the keyboard, such a comparison is nonsensical. They computer can't reasonably say, "Please add 4 bits of entropy to your password," and saying that the password isn't strong enough without providing any guidance as to why will just be frustrating.
4) The library would need constant updating to be valid. Because "correct horse stable battery" and all of the permutations of that set of words (probably including pluralization and tense changes) are terrible passphrases now, but they would have been pretty good prior to Randall Monroe's comic. Each new song, book, poem, and speech decreases the value of passphrase word-sets.
5) Assuming you ignore (4) above, you still basically eventually run into what we have now--some people have good passwords, some people have bad passwords, and the biggest problem is still reusing passwords combined with site compromises.
Re:The main problem is... (Score:5, Insightful)
It means they don't care. I do online banking security consulting, including almost all of the largest banks in Canada. They know that what they have is far from ideal, but the losses are not enough for them to want to make a change. It comes down to a formula of the costs of fraud vs the costs of adding additional security + help desk calls as a result + end user usability. One of the largest banks I worked with told me that banking with them is a cultural thing and that most of the citizens in the province will bank with them by default. They can afford to have minimal security and just cover the fraud loss out of their profit.
And just so you know, Authentication is dead. If I've got malware on your machine, then I don't care how strong your password, OTP and biometric security is. I'm going to wait for you to login and then take over your session in the background. Security at this point is well beyond what's happening at the login stage. And don't get me wrong, the vendors that are doing the current security implementation for these banks have a lot more to offer, but it's the banks that are deciding that it doesn't matter to them.
Re:This is too simple to fix (Score:5, Insightful)
My banking site insists I change my password every few months. It must have a capital letter, it must have a numerical character - and worst of all - it cannot be any of the last 5 passwords I chose. It is only one of about 20 websites I have passwords for (not to mention a half dozen MMORPGs I play from time to time). I cannot remember all of those passwords easily so when I am forced to cycle through 6 different passwords by one single website its a bit fucking irritating. Not only that but I highly doubt it increases my security significantly, and of course my bank account seldom has much money in it in the first place.
Re:This is too simple to fix (Score:5, Insightful)
"Your password cannot be over twelve characters."
"You have used this password before. Please enter a new one."
I have my own password policies, and it's frustrating when I can't follow them.
Re:Passwords DO suck (Score:2, Insightful)
I tried verifying the certificate with the bank before. They didn't even have a clue what I was talking about.
Re:Terrible password policies (Score:5, Insightful)
What's even more facepalm worthy is that when you call, they usually "verify" your identity using information about you which is frequently publicly available.
Comment removed (Score:3, Insightful)
Re:This is too simple to fix (Score:5, Insightful)
Re:This is too simple to fix (Score:4, Insightful)
Actually, I think we emailed you then locked you out, so if you were on-line, you could choose a new password then and there
Sounds absolutely ripe for phishers to send fake e-mails.
Re:Terrible password policies (Score:4, Insightful)