Your Passwords Don't Suck — It's Your Policies

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?"

Comments

This is too simple to fix

[Anonymous Coward]

Every time a see a password like this "12ol3jkh!!asrdfw9g8" or "^TFGY78UH" I want to vomit. Why not make your password something like "This chicken tastes like shit!"

Re:This is too simple to fix

[ClioCJS]

because it would take longer to type

Re:This is too simple to fix

[SomeJoel]

Every time a see a password like this "12ol3jkh!!asrdfw9g8"

That's the password on my luggage!

Re:This is too simple to fix

[The Raven]

The reason to avoid understandable sentences is they have extremely low entropy per character. Or, put another way, they are easier to hack than their length would indicate. An xkcd password has about 1.5 bits per character of entropy; a normal English sentence has as low as 0.6 to 1.3 bits per letter, according to one study. Given the simple and trite short sentences people would use for passwords, it's likely closer to 0.6, or about 20 bits of entropy for your example 'chicken' password, compared to 44 bits for a shorter xkcd password.

Re:This is too simple to fix

[Anonymous Coward]

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:This is too simple to fix

[Kvasio]

because "This chicken tastes like shit!" password is more or less a "5-character password", but characters are selected not from ~26 but from say 50000.

My guess is that after the referred xkcd strip brut force algoritms also put more emphasis to natural language sentences, etc.

Re:This is too simple to fix

[SilverJets]

Funny.

  According to the Passfault demo (that's the link in the summary above) it would take 18384672610116790 centuries to crack "This chicken tastes like shit!"

Where the xkcd password "Correct horse staple battery" would take 72624497 centuries to crack. That is if it wasn't already on the internet for everyone to see and try.

Re:This is too simple to fix

[Anonymous Coward]

When sites like slashdot impose a maximum password length limit like 22 characters, it suggests to me that they don't infact store the passwords as hashes as you would expect. Also garbled passwords are going to be far harder for people to memorize if seen by accident.

Re:This is too simple to fix

[sexconker]

Every time a see a password like this "12ol3jkh!!asrdfw9g8" or "^TFGY78UH" I want to vomit. Why not make your password something like "This chicken tastes like shit!"

Because 12ol3jkh!!asrdfw9g8 is a good password and This chicken tastes like shit! is a terrible password.
Please quote that XKCD comic all you like, it doesn't make it right.

"Entropy" (can we please stop misusing this word?) is only a useful measure of password strength if you're brute forcing.
Password crackers employ methods that are a teeny bit more sophisticated than brute forcing.

Re:This is too simple to fix

[sexconker]

Funny.

  According to the Passfault demo (that's the link in the summary above) it would take 18384672610116790 centuries to crack "This chicken tastes like shit!"

Where the xkcd password "Correct horse staple battery" would take 72624497 centuries to crack. That is if it wasn't already on the internet for everyone to see and try.

That estimate is generated by assuming brute force and a specific character set that contains all of your input characters.
No one cracks passwords starting with brute force.

Re:This is too simple to fix

[roc97007]

Where the xkcd password "Correct horse staple battery" would take 72624497 centuries to crack. That is if it wasn't already on the internet for everyone to see and try.

Yep. (nods). Now if you excuse me, I have to change my password right now.

Re:This is too simple to fix

[JoeMerchant]

Good job printing it on the outside...

Re:This is too simple to fix

[felila]

I tried out the Analyzer program, and discovered that it only seemed to look for *English* words. Simple, easy-to-remember phrases in Tongan or French were rated as extremely strong (taking centuries to break).

Re:This is too simple to fix

[LordKronos]

Actually, it's "correct horse battery staple". And the funny thing is, I didn't even have to look it up. As the comic says "you've already memorized it".

Re:This is too simple to fix

[Mashiki]

Right they steal your table and attack the salted-hash. Sooo...no passwords for anyone!

Re:This is too simple to fix

[fsck1nhippies]

If you have people typing passwords in plain view of others, you have an administrative problem and not a technical one!

Re:This is too simple to fix

[pacapaca]

Clearly the solution is "tH15 Ch!ck3n tas7es l1k3 sH|t!"

Re:This is too simple to fix

[Sancho]

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:This is too simple to fix

[hawguy]

You did not account for the spaces which makes 8. You can also remove the spaces altogether. It is not a matter of "IF" a password can be cracked it is if your policy requires it to be changed before that can reasonably happen. So what makes more sense for a network administrator to employ;
1. 8+ character password with minimum 1 upper, 1 lower, 1 digit, and 1 special character changed every 45 days (which would result in something like $rfVBgt5).
OR
2. 17+ character password with minimum 1 upper, 1 number, 1 lower and 2 special changed every 45 days which would be "This chicken tastes like shit!"

Take your grammar rules and apply them. Even if you were to take the fact that the words come from the dictionary, you would have to break it within the password change cycle. Shorten the password life to 15 days and require that the fist letter be different for the last 2 passwords and you still give users reasonable security without being crazy.

I have 2 red cars and one black.
You like my black car.

People can remember that.

I ignored the spaces, since they only add one bit of entropy - either you have spaces or you don't.

Shorten the password life to 15 days and require that the fist letter be different for the last 2 passwords and you still give users reasonable security without being crazy.

Are you really saying that a 15 day password lifetime is reasonable? Some of my users don't even log in for 15 days, their password may be expired before they even return to a place where they can use a computer.

If you tell users "The first letter has to differ from your last 2 passwords", they'll prepend A, B, C, etc to their password.

Once you start adding rules like "1 upper, 1 lower, 1 digit, and 1 special character changed", then you're getting away from the simplicity of the whole XKCD scheme. And you're not adding much complexity to the password since most people will capitalize the first word, and stick a digit and special character on the end.

Re:This is too simple to fix

[gtbritishskull]

I have 3 different bank accounts, 3 different credit cards, a HSA, a Roth IRA, and a 401k that I should probably make sure have secure passwords. (And I am sure there are a couple more non-financial ones that should also be secure). In an ideal world, that would be 9 different 6-8 digit random character passwords. That is assuming that all of the other accounts (like /.) have less secure passwords. That doesn't even take into account changing the password semi-regularly. Even if you feel it is unnecessary, some websites enforce it on you. I am a pretty smart guy, but I might have a little trouble keeping them straight. How many different 6-8 digit random character strings do you have memorized? And how often do you change passwords on your account? Do you change them all at once (and memorize all new passwords), or do you spread it out?

It only doesn't seem hard if you are not doing it right.

Re:This is too simple to fix

[Phrogman]

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

[wisnoskij]

Well you simply cannot memorise all the passwords that a modern computer user has to use no matter what style you use if you are not taking risks or a memory expert. That is why you need password vaults, or post it notes.

Re:This is too simple to fix

[pgpalmer]

"Your password must be six to eight characters and contain only letters and numbers."
"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:This is too simple to fix

[wisnoskij]

Just like I said, no way to do it safely. That has about the same amount of entropy as a single character password.

Re:This is too simple to fix

[Golddess]

Wait, a password 24 digits long has the same entropy as a password one character long?

Re:This is too simple to fix

[SScorpio]

But what prevents a there being a rainbow table of 12 characters mixed case with special characters? The big thing with having a string of words as a password is that if creates a very large set of possibilities. A word list string together multiple dictionary words isn't going to be much better than a straight brute force attack.

Besides you can easily capitalize a single word or all of the characters in one of the words, and throw in a number and symbol in your sentence you you made your password even more secure while only being slightly less easy to memorize.

thisIS4verysecurep@ssword is much easier to remember than aB38$%| and it would take a lot longer to brute force it.

Re:This is too simple to fix

[spazdor]

Maybe the trick is to do something like "Your password is unacceptable because it can be broken down into 2 substrings both of which get more than 50,000 Google hits."

Re:This is too simple to fix

[roscocoltran]

At leastst my asd45WSd558_315 takes more than 1 peek to be memorized, and people just don't try to watch since it's seems so complicated anyway. If you watched me type the horse thing you would have my password by now.

Re:This is too simple to fix

[arekq]

Good. Then Google have all your passwords.

Re:This is too simple to fix

[Drishmung]

We actually did something like this.

Users were permitted to choose their own password. These passwords could be long. We had guidelines as to what were good schemes, but there was no enforcement of rules.

However, we also

1. ran a quick check on your password against a cracker and
2. ran a password cracker as a constant background job.

If your password was cracked by the quick checker, it was rejected and you had to choose another.

If the background checker cracked your password, you were locked out. When you tried to log on and couldn't, and called to find out why, you were told your password had been cracked and you needed a new one. (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).

It worked.

Re:This is too simple to fix

[mysidia]

but I do know many dictionary cracking programs implement mixing of words on the list - meaning "correct horse staple battery" will be cracked in SECONDS, not centuries.

There are approximately 6000 common words in the English language, so if you just pick 4 random words, there are
6000 ^ 4 = 1296000000000000 possibilities

If you pick a truly random 8-character password, there are:
140 ^ 7 = 1054135040000000 possible choices.

Even at 1,000,000 crack attempts per second, it still takes on average 16 years to crack a password formulated using either method. way.

Re:This is too simple to fix

[SuricouRaven]

I work at a school. Think lots of computers at a desk, all in a row. Every time we ban someone from internet access due to gaming/porn, we find out within a couple of days that they are back on using stolen credentials. Half the time they aren't even stolen, their friends hand over passwords willingly, but there is no way we can prove that.

Re:This is too simple to fix

[the_other_chewey]

I take it you've never seen a wordlist for a dictionary password cracker. I don't have any on me to see if that specific string is in them (quite possible, based on some of what I remember), but I do know many dictionary cracking programs implement mixing of words on the list - meaning "correct horse staple battery" will be cracked in SECONDS, not centuries.

No it won't. I recommend some math instead of faulty intuition:

Let's assume a word list of 5000 entries (that's very low, the OED
counts over 150000 words in current use).

Four words out of this gives us 5000^4 (word repetitions are allowed),
or 6.25e14, that's 625 trillion. At a million cracking attemps per second,
that gives 19.8 years for an exhaustive search.

So, a random four-word passphrase made up from a 5000 word list
will take nearly 10 years (exhaustive/2). And that assumes the passphrase
only contains words from the list. Unlikely.

Of course, 10 years isn't that impressive. But even a single changed
character somewhere – or just a word not on the list! – will require a full
brute-force search on the character level instead of at the word level.

Hello bazillions of years.

Re:This is too simple to fix

[DamnStupidElf]

Even at 1,000,000 crack attempts per second, it still takes on average 16 years to crack a password formulated using either method. way.

Try a billion attempts per second with a single GPU. A maximum of 15 days.

Re:This is too simple to fix

[DarwinSurvivor]

Forget the door, it's easy to see if someone is looking through the door. What *really* amazes me is how many office buildings have completly glass walls and computer monitors in each office FACING THE OUTSIDE (or even at a 90 degree angle). Any teenager within 10 blocks with a telescope could nab hundreds of passwords (and god knows what else) in a single day.

Re:This is too simple to fix

[pjt33]

Mixed case with special characters gives an alphabet of (conservatively) 80 characters. 80^12 combinations * 12 characters to store (neglecting the actual hashes) is 824ZB. That's the amount of data the LHC would produce in about 55 million years. You need some extremely good compression to get anywhere near something you can store on any feasible device.

Re:This is too simple to fix

[Stormtrooper42]

You can always use a password manager (ex: http://www.clipperz.com/ ). I actually don't even know most of my passwords. Don't need to.

Re:This is too simple to fix

[Sancho]

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.

Wrong

[DarkOx]

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

Re:Wrong

[LordLucless]

Of course, your fiendishly clever non-standard spelling of et cetera would fool any such dictionary attacks.

Re:Wrong

[wrook]

The average adult that has been to University knows 20,000 head words. A head word is a group of words with essentially the same meaning. For example, expect, expectation, is expecting, etc are all one head word. 26^7 is a little bit over 8x10^9. If a user picks 4 headwords for their passphrase, the search space is 20000^4 or 1.6x10^17. And that's if we just use headwords. If the user uses variations the search space is rather huge.

You might say that 20,000 headwords includes a lot of strange vocabulary. But for instance, to get 95% vocabulary coverage in reading a newspaper you need just under 16,000 headwords. However, even if we restrict vocabulary to the most common 5,000 headwords (the average vocabulary of a 5 year old) we get a search space of 6.25x10^14.

XKCD style passphrases are dramatically more robust than a 7 character alphabetic password.
 

Re:Wrong

[pongo000]

The trouble with the pass phrase concept is that the whole words just become tokens. Most people's vocabulary is not that large.

That's why you use a standardized list of tokens (mostly words, but some non-word tokens as well) such as Diceware. 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, 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:Wrong

[JoeMerchant]

2140^4 ~= 80^7

I think most paid professionals could come up with a 2100 word vocabulary of words they can remember, especially if you bounce their choice when they use any of the 500 most commonly selected words - they could use the 500 most common, just that they wouldn't get credit for a common word being one of the four.

A 4 to 7 word sentence is a hell of a lot easier to remember than 7 screwy characters.

Re:Wrong

[tknd]

Most people's vocabulary is not that large.

Let's use the xkcd example: correct horse battery staple.

Using a list of the 5000 most commonly used words, I was able to find rankings for 3 of the 4 words:

• 1813 correct
• 1291 horse
• 3226 battery

"staple" doesn't even appear on the most common 5000 word list. But let's assume it did at 5000. That means your dictionary now is 5000 words large. 5000^4 = 6.25 * 10^14.

Now let's address your suggestion:

you don't really have a key space much larger than normal 7 character or so passwords offer

Now your average English keyboard has 47*2 = 94 type-able characters. 94^7 = 6.48477594 * 10^13. The xkcd example assuming it was smaller than it really was beat your suggestion by an order of magnitude.

Now let's address how large people's vocabularies are. According to wikipedia:

This translates into a wide range of vocabulary size by age five or six, at which time an English-speaking child will have learned about 2,500-5,000 words. An average student learns some 3,000 words per year, or approximately eight words per day.

But 6 year old kids don't have much interesting personal information that people are really after like credit cards. Let's read further:

A 1995 study estimated the vocabulary size of college-educated speakers at about 17,000 word families, and that of first-year college students (high-school educated) at about 12,000.

http://en.wikipedia.org/wiki/Vocabulary

So let's re-do the calculations with 10,000 words: 10 000^4 = 1.0 * 10^16.

Things will only get worse if you tell people to use numbers, names, special abbreviations, etc. For example it will be highly unlikely the following phrase will be in your dictionary: "5000 most common vocabulary". People can also use natural language and still fall way out of your dictionary: "yummy carne asada dinner". They can also use personal and vulgar language: "Stupid bitch Alice, never again".

Re:Wrong

[MsWhich]

Earth Fire Wind Water Heart! By your powers combined, I am Captain Planet!

You can keep the bitcoin, though.

Re:Wrong

[0123456]

Fortunately my mother's maiden name is v6g1sH6Ynr.

Re:Wrong

[pjt33]

44 bits is a respectable amount of entropy

Not really. If you look at the latest password cracking speeds (e.g. Speeding up GPU-based password cracking by Martijn Sprengers and Lejla Batina, proceedings of SHARCS 2012), 44-bit MD5-crypt can be brute-forced in 3 years with one graphics card. If you assume that the idiots who wrote the software are using MD5 rather than MD5-crypt, that drops to 1 day. With one graphics card.

another password revealed

[ozduo]

A white jacketed southern gentlemen's password is "This secret spice makes shit taste like chicken"

Terrible password policies

[bu11d0zer]

Any password policy that basically forces you to write down your password somewhere is broken. Sure, you can use a password vault but that's cumbersome for the various dozens of passwords strewn about the web and on mobile devices. But my biggest gripe is sites that lock you out (requiring a phone call) after 3 incorrect guesses. I could understand 100 incorrect guesses, but 3 guesses is not enough to recall a password when you have not used it in several months. One hundred guesses by a computer/hacker is nothing compared to the full password space.

Re:Terrible password policies

[oneiros27]

My company's password policy is that you're not allowed to use password vault software.

I wish I were kidding.

Oddly, though, the new policy came out a month or two after the xkcd comic, and they *did* make a special exemption for using dictionary words and the other password complexity rules provided the password was of sufficient length.

And I think most of the systems will lock out after between 3-5 failed attempts, but they'll automatically unlock after 5-15 minutes, so you don't have to call in.

Re:Terrible password policies

[Solandri]

But my biggest gripe is sites that lock you out (requiring a phone call) after 3 incorrect guesses.

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.

Re:Terrible password policies

[doomday]

100 attempts may be small enough to stop a random computer or hacker, but it may not be low enough to stop your buddy who figured out part of your password while you were typing and wants to play a prank. That is one reason the limit needs to be pretty low.

What puzzles me...

[jbwolfe]

...is why is it all so difficult to come up with some scheme to secure internet accessible resources. Corporate policy for me require password changes every 90 days and disallows any of the last eight passwords, and the use of letters and numbers. Effectively, I'm forced to write it down, negating all their efforts at obscurity. When will some bright CS geek invent a real solution to this problem. Is it that hard? Can't it be as simple as probing me for dynamic info that only I would know? How about visual methods- ask me who's in this picture of my co-workers or what is this family snapshot from my past, etc.?

Re:What puzzles me...

[youngatheart]

When will some bright CS geek invent a real solution to this problem.

Answer: they have and do, and even when they get around all the pre-existing patents (either by licensing or finding yet another idea) the sell and implementation are difficult hurdles to overcome. First the example you give is one very close to another I've seen sold by a company and I'm sure is patented. That makes it either expensive or out of the question right up front. Then there are other issues to keep it from being implemented.

Often the writers of the software that is in the backend of the system are long since gone from the companies that depend on them. Rather than hire expensive work done to correct the problem, companies choose instead to attempt to bend the front end of the system to meet the requirements of the back end. While that at least is possible in most cases, that requires a programmer that is willing and competent to put the work into such a system and, again, those programmers tend to be the experienced and expensive ones.

Take unix systems that used to only allow for six or eight characters. It would be possible to rewrite the login prompt to take the input of up to 500 characters, salt it against itself and then using the result, determine which pair of a hundred tables of random characters the original would be xor'd against and then hashed to where the resulting hash of the process uses a full ascii set with a limited resulting length matching the maximum original limited length to then submit that as a final password to the underlying authentication. The concept isn't horribly complex and the results would be good, but you have to find somebody that you can get to rewrite the login prompt, somebody else with expertise to validate the procedure and potentially in the future, someone to modify it if demands change or add it to new systems that are authenticating on top of it. On top of that, you have to be able to present a credible defense to outside auditing companies if the data you're protecting is in any way valuable. Alternatively you could hire somebody to update the existing backend validation system and handle the transition process with minimal impact. Either choice is feasible, but both are expensive and in many cases give you a custom system that is no longer supported by default from the upstream software provider.

Don't underestimate the requirement to satisfy auditors either. Auditors are rightly suspicious of home grown security systems. The auditor probably understands "the standard Microsoft requirement for a minimum length of ten characters with no less than three non-alphanumeric characters that doesn't duplicate any of the last eight passwords and updated every ninety days." The auditor probably doesn't understand "A scored input system requiring a minimum complexity of 30 bits processed using salts and algrothims to determine xor tables, then processed with a modified sha2 for an eight character ascii value drawn from the full ascii set, then reprocessed as a standard submission."

Take Windows as an example. There are a variety of alternative authentication systems you can add on for example, but if you do then you can't hire a random windows admin and have them administer the system without additional training. Even if you do, then you have to prepare yourself to maintain the system and have a sufficiently documented system to present to auditors each time they review your system. It is far simpler and cheaper to use the standard "every 90 days, and this type of requirement" policy everybody is already familiar with.

Re:XKCD

[spazdor]

Sure, its 28 characters, but its still lowercase only.
That makes it a lot weaker, no?

It makes it weaker by a factor of about 2^28.
Which sounds like a lot, but when the lowercase password space is already 26^28, it's not much.

XKCD's math is sound.

Re:XKCD

[aztracker1]

I will usually do something that is a short phrase, separated by hyphens or spaces, with the first letter capitalized, and one of the words l33tified. Tends to work very will with 12+ character passwords. Though I've been considering doing something new using a generator.

I really wish that more places would simply let you use a long password, and use confidence testing with something like this, or like the Wolfram Alpha algorithm for password strength. I get sick when I'm limited in length, or need certain characters, or others are disallowed. anything in the ascii 32-126 range should be allowed.. with the input trimmed so leading/trailing spaces aren't included. (For that matter, if you can use UTF-8, do it, again trimming, and eliminating control characters (<ascii 30)

Re:XKCD

[Beryllium Sphere(tm)]

The OED Second Edition contains entries for 171,476 words.

If you choose at random from the complete set, there are 8.6E20 possible four-word passphrases.

This is enough to rule out brute-forcing. But notice of course that both assumptions are critical. An average person doesn't have a 171,476 word vocabulary and humans can't make genuinely random choices.

I recommend the Diceware system: a list of 6^5 short words, from which you select each word of your passphrase by rolling five dice.

All of which addresses the wrong problem. Online guessing can be suppressed with rate limits on login attempts. Offline guessing is greatly hindered by adequate salting of the hashes. Today's most dangerous threat is phishing (well, that and password reuse, but that's a related problem).

The main problem is...

[k3vlar]

The main problem is indeed the policies. While I (mostly) agree with the main statements TFA makes, I have my own note to add:

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:The main problem is...

[John Hasler]

> I fear for my online bank info constantly .

And yet you continue to deal with that bank. Why?

Re:The main problem is...

[youngatheart]

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 so I won't repeat it here for the sake of brevity.

Re:The main problem is...

[Anonymous Coward]

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:The main problem is...

[Osgeld]

apparently you didnt understand

a random short password is less strong than a simpleton long password

if you mix the two you get even stronger, if you speek "leet" you would have read that password as normal english, and its something the OP could very easliy remember WHILE increasing length AND adding bits

25 still beats the shit out of 6

its not the content its the length

Re:XKCD

[Zocalo]

Well, you can probably blame Little Bobby Tables for that. Depending on the programming language there are plenty of "control characters" in the ASCII 32-126 range, and it's much easier when deadlines are pressing to just restrict input to alphanumerics than try and sanitize against passwords that contain some variant of "'); drop table students;"

Re:XKCD

[hawguy]

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...

[NoMaster]

Congratulations on winning the Slashdot trifecta - you managed to invoke the GPL, cite XKCD, and slashvertise your own project all in one!

Re:XKCD

[spazdor]

No, it would be "weaker by half" if the alternative was a single capital letter at the beginning of the password.

In fact, the alternative is that any, some, or all of the 28 characters could be capitalized or not.

So the first character halves the password's strength if it is predictably lower-case.
and the second halves it again.
and so does the third.

Incidentally, halving or doubling the key space is not "a lot," not by any cryptologist's standards.

Re:XKCD

[baileydau]

The only thing going for it is that you don't know that it's only lower case letters.

I think this is a very important point that lots of people overlook.

By prescribing the use of various character classes, you are actually weakening the password.

A proper password should allow the use of those classes, but not prescribe them.

When I was a kid, we had a game called "Mastermind". One person selected various coloured buttons and hid them behind a screen. The other person had to guess the colours / sequence.

We had various house rules about difficulty levels. One of the easiest ones was if they had to tell you the pattern. eg:
* double colour
* blank
etc

Same thing with passwords

Re:XKCD

[spazdor]

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:testing the password

[JustOK]

wait for the beta

Re:XKCD

[sexconker]

sanitize against passwords that contain some variant of "'); drop table students;"

Uh...methinks you're doing it wrong. What if I wanted "'); drop table students;" to be my password??

We had to reject several applicants because when asked how to prevent SQL injection, they said "Strip out words like UPDATE, DELETE, INSERT" ... well, what if we want to use those words??

Parameterize user input and stop worrying about SQL injection. This isn't 1992.

Re:XKCD

[Zocalo]

The problem isn't the use of the phrase "drop table students" so much as programmers under pressure, or just being lazy, having to code for the use of characters like semi-colons, brackets, braces, pipes and all those other symbols that tend to cause problems if not correctly handled when returned in a variable. It's an even more tricky situation if the person coding the password input routine is not the same one coding the authentication routine, which happens quite a lot on large projects. It's much easier to code a simple "if password contains {list of symbols} then reject password" than it is to escape each of those symbols and then liaise with everyone else who is using the password variable to make sure they can deal with the escaped characters.

Of course, if it were understood that the password input routine was going to immediately hash the password into a suitably safe string and that was what would be returned in the password variable, then most of these problems simply go away.

Re:Passwords DO suck

[sexconker]

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.

Randomly-generated passwords

[dskoll]

I use randomly-generated passwords (generated by reading /dev/random) that are at least 16 characters wrong. I restrict the character set to [A-Za-z0-9] which is a touch under 6 bits per characters, so I have about 95 bits of /dev/random-quality entropy.

The passwords are stored in a file encrypted with a long passphrase. The long passphrase is probably the weak link, but by not reusing passwords across different websites and using randomly-generated ones, I'm fairly well-protected if one of the sites I visit has its password file stolen.

Re:Typos

[roc97007]

The problem with XKCD style passwords is the more characters in a password, the more likely I am to make a typo while entering it. I mistype a typical 8 character password a couple times a day. I can imagine what it would be like with a 25 character password.

Um..... practice typing more?

The thing with xkcd type passwords is that they are made up of english words (or whatever your native language) which you have probably typed a million times before. How could you not type them correctly? I just typed this sentence without a single mistake and it contains 49 words.

Security questions & other sucky policies

[justthinkit]

Q: "What is your pet's name?"
A: "What are stupid questions I don't want to answer truthfully, Alex?"
.

Also unwise is to have web sites save your info, especially credit card info. Someone cracks the db and you are p0wned.

It is more than just passwords...Heh, don't click that link, Grandma!

Hide in plain sight

[Roger W Moore]

Also garbled passwords are going to be far harder for people to memorize if seen by accident.

Not if they do not recognize it as a password e.g. "Remember the lepton-jet meeting at 8am" would look more like a reminder than a password.

Re:Hide in plain sight

[donaldm]

Also garbled passwords are going to be far harder for people to memorize if seen by accident.

Not if they do not recognize it as a password e.g. "Remember the lepton-jet meeting at 8am" would look more like a reminder than a password.

You could do this to the sentence in quotation marks "Rtl-jm@8am". Easy for you to remember but a real bitch for someone looking over your shoulder. Actually a better way is to poke the guy in the eyes who is looking over your shoulder :)

Re:Hide in plain sight

[real-modo]

You could do this to the sentence in quotation marks "Rtl-jm@8am".

Let's see: Windows cipher, $180,000 password cracker: "Remember the lepton-jet meeting at 8am" has time to crack of 1876294336154520 centuries.

Windows cipher, average graphics card based cracker: "Rtl-jm@8am" has time to crack of 1 month, 10 days.

You've converted a strong password into a very weak one.

I mean this as a gentle, polite hint: try learning something about passwords. Google "diceware" for one beginner's starting point.

Re:XKCD

[poopdeville]

You are totally missing the point.

Instead of using an "alphabet" with 26 characters (or 52 with capitals, or 70-something with capitals and punctuation) and choosing a short random string, you use an "alphabet" with 5000+ ideograms (i.e., words) and choose a short random string of these words.

For simplicity, just suppose there are 5000 commonly used English words. Then there are 5000^n passphrases of length n (i.e., containing n words). Obviously, this is much, much bigger than 70-something raised to the n. It does not matter that it is smaller than 70-something raised to the number of characters in the passphrase.

As a matter of fact, my computer's word list contains about 95,000 words. Try to guess the password I will generate with the following algorithm:

Pick 7 random numbers between 1 and 95000. Look at the word indexed by the random number. Memorize.

My PRNG yielded:
74019,69542,70792,42388,32916,63978,55632

which maps to:
purchasing persecute platitudes escalations consummation mum intoned

A quick calculation shows that such a scheme has about bits 115 bits of entropy, compared to less than 44 for a "character" password with the same number of random tokens drawn from the alphabet.

So what's the big deal about using words instead of just longer random strings in the smaller 70-something character alphabet? You would need an 19 character random string drawn from an alphabet of 80 to get as much entropy as 7 words drawn from a dictionary of 95000 words. Clearly, the latter is far easier to memorize than something like "DtnqaELdIA=vozSkC" and provides the same cryptographic strength.

Highly secure NSA and DoD passwords

[kriston]

The highly secure NSA and DoD password policy is very thorough, but one thing was left un-noticed about this policy. You can create a valid password by merely running your finder down a colum of the keyboard, and then holding down the shift key and doing the same thing. Really!!

To wit, this password is valid. Run your finger down the left-most column of your keyboard: 1qaz2wsx
Then hold down the SHIFT key and type !QAZ@WSX
Presto, you have a valid password that meets all the security requirements the NSA and DoD have imposed upon you.

Now that's okay for creating system images for deployment.

In 45 days when you need to change your password again, just shift to the next row of your keyboard. This will keep you okay for a couple of years or so until you run out of keyboard rows to use. Then, you just do it backwards. It really is that simple.

Try it!! It's almost unbelievable.

Re:Passwords DO suck

[Anonymous Coward]

I tried verifying the certificate with the bank before. They didn't even have a clue what I was talking about.

Major bugs

[Georules]

Just did this:
Start with "awesomepasswordtoday"
1 year, 8 months
Go to "awesomepasswordtoday000"
7 centuries, 8 decades
Go to "000awesomepasswordtoday000"
less than 1 day

This tells me there is something in the logic that makes it a pretty unreliable metric of password strength.

Re:XKCD

[arose]

Your password complexity requirements are worthless, users will pick easy to remember, insecure passwords no matter what the requirements are. They will, of course, literally fullfill the requirements. The difference is that you are much more likely to get user cooperation if password changes consisted of the computer picking 4 random words for them, rather than 12 random alphanumerics with a side dish of ASCII barf. The only reason users pick their own passwords for sensitive applications is that they'd write that shit down and stick it on the monitor (or under the keyboard, for the ones who "understand security") if you made it truly secure (i.e. generated it for them).

Right now your users pretend to pick secure passwords and you pretend that they do. You don't want to know how shitty they are, they don't want to tell you. As long as you don't find them on post-its and there is no visible compromise everyone is happy. Of course they should have PIN-secured, challenge-response based one time password generators, but let's face it, your systems just aren't important enough to secure them in a thoroughly user friendly manner. So if you actually do care beyond your users picking the simplest password that passes your requirements you very well might think about randomly generating 4 word passphrases for them, I think you even have some volunteers for a trial.

Re:XKCD

[tqk]

I'm glad that there are people who care enough to analyze the strength of things that are so strong they just don't matter.

For some people (I'm one), the problem is the point of it all. Banging your head on that for days, weeks, months, years, is fun. That's what it's all about. A sexy problem's like gold. If you find the solution, (figuratively speaking) "Now what am I going to do?" Einstein spent most of his life fruitlessly banging his head on gravity. A good problem's addictive.

Anything that lasts beyond 100 years cracking time on $100K worth of hardware ...

Somebody recently (a couple of years ago) demonstrated a build it yourself Beowulf that'd do < $100/Gflop. That's verging on "anyone can have one" territory.

If somebody feels they want to spend several months tying up a $100M cluster to break a secret they think I hid somewhere, I must have done something remarkably important with my life.

They could just be practicing on you. Once perfected, they'll have Putin's emails, or Berlusconi's sex tapes, or GWB's smoking guns, ... I agree, this subject is a bit dumb, but if you happen to be that one in a million who looks at a problem in just the right way that a possible solution presents itself to you, would you just blow it off? Me, I can't. I've got to look into it, until it falls over or I get hopelessly lost trying.

Sometimes, for some people, the journey's the thing. Getting there's optional. Beats being Jack the Ripper. What a shitty hobby that was.

Re:Unreliable cracking estimate

[lewko]

Since when is coprophage rare? This is the Internet.