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

[sexconker]

The characters are "words in a dictionary" not "glyphs on a keyboard".

But when cracking a password, you look at "words morons on the internet use a lot" and there are probably closer to 5000 of those (compared to 50000 regular words). Combine with noun / verb / article classes and weight words with frequency and you can narrow that down to a LOT less in practice.

Pass phrases are dumb.

Re:This is too simple to fix

[spazdor]

Why exactly do you think 'entropy' is the wrong word? It's a pretty well-formed concept in information theory.

Re:This is too simple to fix

[hawguy]

I am not sure how you consider this a 5 character password. The breakdown in usage is

...

A lot more than 5.. That are 14 unique characters in that phrase.

Because there are 5 unique tokens:

this
chicken
tastes
like
shit
! (actually 6 tokens including this special character).

But I don't think it's true to say that each token is drawn from a pool of 50,000. These are common english words that probably exist in a dictionary of 1000 common words. A strong password would use less common words:

        the aforementioned fowl has a sapidity analogous to excrement

but you really don't want a complete sentence since grammar rules could be used to brute force it, so just put the words together without proper grammatical structure:

        aforementioned fowl sapidity analogous excrement

But, of course, this makes it harder to memorize

Re:This is too simple to fix

[gtbritishskull]

Of course... if I can't memorize it, how the hell is anyone else going to memorize it?

Re:This is too simple to fix

[gtbritishskull]

Depends on how you define a "good" password. If I have to store my passwords in a note-taking program on my phone (probably without any encryption), then how "good" are they really? Or on a post-it note stuck on the monitor. Or written on the bottom of the keyboard. That is the fine line you have to walk with security. You want to make it as hard as possible for the bad guys, but that adds complication/inconvenience for your customers. And if you make it too inconvenient, then your customers will circumvent it and add new points of entry for the bad guys.

Re:This is too simple to fix

[Anonymous Coward]

So the " " and "!" or the case sensitive "T" do not count as additional words?

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

[JoeMerchant]

I would counter that people can more quickly and easily type and remember a sentence such as:

my quick brown rabbit

than they can:

!Tdg7wrth

and the entropy is roughly the same. How about instead of f-ed up requirements like special characters, upper/lower and digits with a length of 8+, we widely distribute a standard library method for computing password entropy and let people pick what kind of strong password they want to remember instead of forcing the issue to the point where everybody is writing their passwords down?

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

[aaronb1138]

Correct me if I am wrong, but understandable sentences only constitute weak passwords if the attacker is aware of the likelihood of a sentence based password or if the encryption algorithm can be attacked by partial password fragments. I know old school NTLM was a terrible example of this since it could be attacked by fragments.

Assuming proper encryption in the authentication system and attacker ignorance of the target personality, a moderately long password requirement of just >12 characters, would be much better than relatively common required >7 characters with at least 1 number and 1 punctuation mark.

Similarly, a secondary password based on a CAPTCHA would probably increase things by a few orders of magnitude. By this I mean something similar to a sign in key, symbol, glyph, swatch or color, etcetera, which the user has created responses to, but with less requirement than the password itself. Each symbol would obviously have invalid reserve words during setup. E.g. a picture of a stop sign cannot have "stop", "sign", "brakes" or any combination, but the word "arrest" could be valid. After entering a username, the system could render the symbol from your selections, for example, there are 30 available symbols, you must pick 4 and create unique responses for each. Further, the authentication system should be ambiguous as to which field was incorrectly filled out. Actually it shouldn't even know if the passwords are used to salt each other uniquely.

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

[fsck1nhippies]

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.

Re:This is too simple to fix

[JWSmythe]

    I wonder how legitimate this is. It's probably legitimate in what it's finding. It's also asking for lots of data to datamine. How many people are going to put in the various passwords they use? This sounds like a great way to further populate rainbow tables, and identify more patterns to build better rules for password cracking attacks.

Re:This is too simple to fix

[theshowmecanuck]

Someone let me know if I'm missing something (just asking because I know at Slashdot noone likes to tell us how they really feel :). Anyway, isn't the 'time to guess or crack the password' based on a system that let's you try to log in or guess it 1000 times a second or more. Many systems where real users log in should have a 1 - 3 second delay between login attempts or a 10 second wait every 5 attempts ... or even 10 minutes. Heck, normal web latency usually means a second delay at least, anyway (granted as technology increases speed this will decrease). With a one second delay and a couple minute wait every 5 attempts, the 3 days would be at least 300,000 days. Make it a 10 minute delay or a lockout on critical systems, then who knows how many days. Likely I wouldn't need that account by then or may have decided to change my password on my own. So to me this whole thing about cracking your password in three days seems extremely far fetched.

So isn't it a case of, in theory typical passwords can be cracked quickly. In reality they can't.

On an aside there is punch line to a joke that says: In theory we're sitting on 2 million dollars. In reality we're living with a couple of whores. On that note, have a nice Victoria Day.

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

[blueg3]

It doesn't how much entropy per character it has. It only matters how much total entropy it has.

Re:This is too simple to fix

[JoeMerchant]

Well... I'd say that if your password is good enough that a computer can't tell it sucks, then it's probably good enough.

I'm far more worried about 'bots trying to crack my password than actual human beings... even at internationally farmed out labor rates and super speed, a penny might buy at most a hundred human generated password guesses, while a penny worth of computer time can try millions.

By the time it costs a couple of thousand dollars to crack a password, aren't we strong enough?

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

[fsck1nhippies]

The fact that you have to test whether or not it is a pass phrase increases the complexity by itself. "This chicken tastes like shit!" is actually 7 "characters" for a dictionary based attack. Your statistical attack on the common language patterns still yields a password with more complexity than @reAp3r.

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

[PIBM]

If the database is compromised and the hashes and salts of the passwords obtained, they are free to try locally to find the corresponding password, thus the delay you are speaking of need not apply.

Re:This is too simple to fix

[outsider007]

Easy for some people but what about Mitt Romney?

Re:This is too simple to fix

[fsck1nhippies]

I was not trying to be reasonable with the 15 day remark. I was exaggerating. If you remove the 1 digit from "1 upper, 1 lower, 1digit, and 1 special character", you have a pass phrase. The user adding A,B,or C to the beginning of their password is a good thing as well. "This chicken tastes like shit!" to "AThis chicken tastes like shit!" destroys the basic dictionary attack. The point I was trying to make is if the password is of reasonable complexity to avoid cracking within the password change period you are effectively securing the system. Besides, who is going to allow more than 4-5 bad passwords before locking the account?

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

[turing_m]

I would like to see XKCD's working out on both his "Tr0ub4dor&3" password and his "correctbatteryhorsestaple" password. What is the N and what is the L, and how did he come to that conclusion?

Nevertheless, using an English dictionary as a source of easily remembered, huge L is a good idea. Unfortunately most of the world limits passwords to something in the 8-20 character range, making this idea something of a Dvorak keyboard layout in terms of its superiority but general impracticality - as the world has standardized on a potentially inferior password creation idea. It's got more chance of catching on than Dvorak though, because there is no cost to each individual website or application enabling long passwords.

That being said, anyone using the password generation feature of a password manager will always have more bits per number of characters than the XKCD scheme.

Re:This is too simple to fix

[fsck1nhippies]

There is a better chance that Mitt would be at his desk to actually type a password in.

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

[negRo_slim]

It's quite simple really, you memorize three or four 8 digit strings and then recombine them in various ways for various accounts.

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

[bky1701]

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.

Add to that rainbow tables, and you're basically screwed with anything under 8 characters + mixed case + at least one special character (ideally an uncommon one like ^, %, or &, less likely than !, @, $, or * to be in a character set).

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

[spazdor]

There are on the order of several dozen intuitive ways to combine 3 strings of 8 characters. So yes, there are about as many generatable passwords in your method as there are possible values for 1 character.

Y'see, reusing a string does not significantly add entropy. That is why zip compression works.

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

[Dan541]

because your suggestion contains dictionary words whereas the chances of I password like "MhVFnGScXZTCYJ6r#YBC5Y2Bn" ever being guessed is extremely remote.

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

[imbusy]

You don't come out of the basement very often, do you?

Re:This is too simple to fix

[Air-conditioned cowh]

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 after all that effort they still let someone else (you) see it!

Re:This is too simple to fix

[arekq]

Because:
- it is bad policy to use the same password in multiple sites.
- when you have dozens of passwords, pass-phrases does not make it easier to remember. it is also difficult to come up with multiple pass-phrases.
- it is easier to randomly generate password and use password manager.

Why would you be looking at people's password?

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

[colinrichardday]

For the first one, 72^11=2.7x!0^27 (52 upper/lower case letters, 20 symbols, although more might be usable). For the second, 26^25=2.4x10^35.

Re:This is too simple to fix

[colinrichardday]

Of course, it depends on how many words are in the phrase. With 9 words, 5000^9 is almost 2x10^33.

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

[TheLink]

If the database is compromised it usually means the site is compromised, which means
1) your data in the site/database is already compromised.
2) your passphrases with that site could be compromised no matter how long they are.

What you really should do is use different passwords for different sites or different security levels.

FWIW even a 6 character password is good enough if a crappy site that you don't care much about is more likely to be pwned by some PHP/.Net exploit before the hackers or whoever guess/brute force your password via the login form.

Re:This is too simple to fix

[Scarletdown]

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

I just tacked on a couple zeros to see what that is in years, and found it mind numbing (nearly 2 quintillion?) So, according to this graph: http://en.wikipedia.org/wiki/Graphical_timeline_from_Big_Bang_to_Heat_Death would the universe be in the degenerate era or the black hole era by the time the password was cracked? My brain has a hard time processing numbers in the 1E1xx format.

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

[TheLink]

I disagree. XKCD says 44 bits of entropy. Which is:
2^44 = 1.7592186 Ã-- 10^13

Which to me means a 2000 word dictionary is assumed, and it's: 2000 * 2000 * 2000 * 2000
2000^4 = 1.6 Ã-- 10^13

Which is a more reasonable way of attacking - since the attacker would be selecting words from a dictionary.

Re:This is too simple to fix

[rossz]

And how is memorizing a 6-8 digit random character password hard?

When you have five different passwords for work and company policy requires you to change a couple of them every three months and you can't repeat the last 10 passwords you used, then lock you out after three failed attempts because you got them mixed up. Oh, the password you meant to use? It's now on the "can not use" list, thus making it even more difficult to remember them.

Our password policy is set by some non-techie middle manager in Tokyo who probably read some lame article ten years ago. Getting a corporate policy changed in Japan is close to impossible, no matter how stupid it is.

A password vault is the only viable option. Which means all of your passwords are now protected by a single password, thus reducing overall security even more.

Re:This is too simple to fix

[dbraden]

It'd be pretty silly to print it on the inside! Sheesh, some people...

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

[Trahloc]

I use to do that. I've moved over to encrypted database with one long ass password to access a list of unique passwords for each account. With 300+ passwords across various personal and business sites there just aren't enough ways to mix up 5 different passwords varying from 8-12 characters. You're going to have repeats, even if you combine multiple passwords, cut them in half and glue them together, or intermix every other character like I did before I swapped to a db. I ended up forgetting what method I used to mesh the passwords together after the 100th account.

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

[DamnStupidElf]

Well, for one thing, anyone who crawls the web will encounter the phrase "This chicken tastes like shit!", for instance at marcegan.blogspot.com/2010_09_01_archive.html. The first random character password only shows up on slashdot in google, and the second isn't even there yet.

If Google can crawl the public Internet a dedicated cracker can just try all short substrings of the public Internet.

Re:This is too simple to fix

[greyblack]

Then i'd be having this conversation face to face with him. [que Moby]

Re:This is too simple to fix

[DriedClexler]

Oh, I know, right? Just the other day I was skimming over our plaintext password file, and it was just filled with crap like that! I mean, they think they have these brilliant passwords, and yet they also complain about their accounts being cracked all the time!

Re:This is too simple to fix

[pjt33]

SilverJets clearly hadn't.

Re:This is too simple to fix

[laejoh]

If you really want speed, go for a $5 wrench!

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

[Carewolf]

There is a difference between online passwords and offline password. First of all there are so many weaknesses online that your password is not going to be the weakest link, secondly online services will typically have system that severely slows down online attacks.

Offline attacks will often attack the digest, and not give a shit about guessing passwords.

Re:This is too simple to fix

[lewko]

Apple do the same shit. And because it's hard to remember the newest incarnation of the password, I end up resetting it which contributes further to the problem.

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

[Erikderzweite]

If peeking is a major concern, why not use Keepass or similar? With Keepass I can copy-paste my passwords (which are random-generated for each site) with people filming my desktop: they won't see the passwords at all.

Re:This is too simple to fix

[allo]

but ... you're not selecting the words at random in a "this chicken tastes like shit" sentence. some easy logic like "only one verb" would reduce the wordlist for the other words a lot

Re:This is too simple to fix

[MickLinux]

Okay, here are several methods:

      (1) Passwords you have to change: Base it on a song you like, and work through the song. Change enough characters to numbers, and pick capitalization, to make it meet the policy.

      (2) Key codes (pins). Start by making a story up that describes the motion of your hand. Your hand will quickly memorize the pattern on its own... the trick is to get your brain to memorize it before your hand learns it.

        (3) Key codes (long codes). Similar story: Make a picture swype, and learn that. Then go through the motion of the swype, right before entering the code. Punch in the keys that your hand would have touched, had it swyped. (That's swype as in Skype, and refers to the Android and perhaps IPOD way of unlocking a phone.)

      (4) Long, seldom used passwords. Sorry-- for this one, you're going to have to have a password-encoded wallet, in which you record your seldom-used passwords. Ideally, you won't keep really secure information in such accounts, anyhow, but we know how stupid the information gathering policies are in the US. The alternative, is just don't use such accounts.

Re:This is too simple to fix

[kermidge]

What's wrong with using LastPass and tweaking the generated password to match a given [stupid] policy?

Re:This is too simple to fix

[TheLink]

BUT how would the attacker know that? Show me your attack plan. If the phrase is in your phrase dictionary that's great... FWIW google turns up 294 results for "this chicken tastes like shit" that's not what I call a popular phrase.

So it's not that simple from the attacker's point of view once the target is using words and the attacker is trying to make cleverer attacks. Make the wrong assumptions and you may _never_ get the answer. Even not using spaces as the delimiter between words can screw attackers up a lot. Or using semi random delimiters... Or not spelling chicken the way it's spelled in the attacker's dictionary!

For 8 character passwords barring UTF-8 craziness brute force is plain brute force, where in theory given enough computers and time you WILL eventually get the answer. But for the passphrases and dictionary approach you're picking possible paths to brute force. If you pick the wrong paths to try, you will NEVER get the answer even if you take infinite time. To eventually get the answer given infinite time you'd actually have to treat it as a character based password and brute force it character by character.

Re:This is too simple to fix

[wisnoskij]

If that password is made up of 4 reused tokens that are can both be learned through getting ahold of just one of your passwords once or though a dictionary attack.

That is like saying 12345678910111213141516 is a great unbeatable password because it is long.

Re:This is too simple to fix

[Jarik C-Bol]

only if someone who knows your password system breaches one of your accounts, and knows about all the others. And even then its questionable, because knowing were the breaks in the 8 digit strings are is required. 1 digit left or right, and the factor goes back through the roof.

Re:This is too simple to fix

[wisnoskij]

If it is made up or only 4 tokens that can be learned through finding just one or your passwords once or a dictionary attack. Compare those 4 tokens to the 90ish characters I have to choose from on a normal keyboard.

That is like saying 1234567891011121314151617 is a great password because it is long.

Re:This is too simple to fix

[wisnoskij]

But one password cannot be easily broken if it is well picked and not written anywhere.

This is the absolute safest situation in my opinion, and if you have a 6-8 character completely random password with special characters and all that other nice stuff then it is impossible to get your other passwords.

Re:This is too simple to fix

[allo]

okay, as an attacker, i do not have 3000 word dictinary, but a 1000 word verb-dictionary and a 1000 word noun dictionary, maybe 1000 attributes as well.
then i generate sentences, which include a verb/noun/attribute ratio, like its common in spoken language, so i will match many phrases, which are like the ones someone who should choose a passPHRASE would make up. lets assume 3 words, then i come from 3000^3 to 1000^3, or more general verbs*nouns*attributes, when the phrase is something like "attribute noun verb". just add an article, but that very little entropy compared to the wordlists, and you get "the brown fox jumps". again some little entropy for the he/she/it s after jump, but thats nothing compared to choosing a word which is more rare.

Re:This is too simple to fix

[allo]

> if you take infinite time
nope. there are only countable number of passphrases, independent of the path you enumberate them. so you can find every finite pathphrase even in finite time, only depending on the length of the passphrase. The path used for enumberation is only a constant factor.

Re:This is too simple to fix

[TheLink]

That approach would not find "this chicken tastes like shit" even given infinite time.

Re:This is too simple to fix

[houghi]

At my job every 1st workday of the month I change all my passwords. I will change them to include something of both year and month. I must have 8 (some systems can not deal with longer ones) so I add a semi random word with at least one capital in it. e.g. my password for this month could be:
1205Tinc

Using this system for many years now.

Obviously this does not take into account the passwords that I am unable to change.

Also it does not take into account the many usernames I have been given.

I use 5 different password
1) Home system
2) Remote systems. Changed once a year. This includes email, sFTP and ssh.
3) Websites (e.g. /. ) Pretty unsecure
4) Bank, Credit Card, ... : Secure and the same all over, but not the same as at home or remote. Change them once a year
5) Work: Changed monthly

So I need to remember 5 passwords. I am able to do this since at least 10 years, if not more.

Remember that you can use many systems for the monthly password:
Xxxx1209, 0912Xxx, 12XX09xx, 2Octxxxx, Oct12xxxx and what not. The advantage is that it does not cause problems with the "Can not use the last 30 passwords". Also if the company IT messes up and reveals my last 30 password because they are not hashed, then all I will looses is the security to my work files for which they are responsible in the first place.

Mind you, I had once access to such files. When I told them I got a simple 'Meh!' as response. SO I started telling as many people as possible that the file existed, so I would not be held responsible if something would happen. Yes, I kept an email trail.

Re:This is too simple to fix

[houghi]

A is a word, so I just use "a a a a" and it is as secure as any other 4 random words likepneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism Floccinaucinihilipilification

Re:This is too simple to fix

[TheLink]

The entire string has to be an EXACT IDENTICAL MATCH for success[1]. Not just look similar.

Example of how you might not get the answer even given infinite time, assuming you are not doing a character by character brute force. Just a word not being in your dictionary or unexpected delimiters will cause you to never find the answer. If the person uses dashes as delimiters, and you never try dashes you will NEVER find the answer even if you take infinite time. Even if your generator comes up with the same words but with spaces between them instead of dashes.

In the same way if you make too many assumptions about the structure of the passphrases and you get them wrong, you may never get the answer either. e.g. verb or noun not in the place you expect. Because the exact correct string will never be generated by your scheme.

Therefore if you target "this chicken tastes like shit" style passphrases, it may prevent you from finding even slightly different types of passphrases. Yeah you can target all sorts of styles if you want, but you better have good statistics on which styles really are common, otherwise it won't work and you are better off doing the brute force any word by any word approach.

[1] Strictly speaking if hashing is used you just need something that results in the same hash, but let's ignore that for now OK?

Re:This is too simple to fix

[Electricity Likes Me]

Except the common occurrence is a website gets compromised and they get a plaintext dump of all the passwords.

You can hold onto that data, and match usernames against each other then, or just try your luck with an email account.

Re:This is too simple to fix

[Larryish]

Like when you mistype "su" and press enter, then type your password without looking at the screen.

Now your password is in your shell history.

Re:This is too simple to fix

[mysidia]

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?

"Your passphrase-style secret is unacceptably weak. Please make one of the following changes to improve its strength:"

• Revise your passphrase so that it contains additional tokens which are not valid words or valid simple transformations of words, at least one capitalization error, and at least one spelling error, example: "this %@^* taStes like chiken."
• Revise your passphrase so that it contains at least one noun, at least two pronouns, at least two adjectives, at least one adverb or gerund, at least one verb, and a comma splice or at least two direct objects: "This bloody shit almost tastes like your homemade chicken noodle soup."
• Revise your passphrase so that it contains multiple capitalization, punctuation, grammatical errors, and spelling anomolies, example: "thiSs heR shi-t tAste like ChicK en"
• Revise your passphrase so that it does not match a sentence found in any work of literature or public writing.
• Revise your passphrase so that it contains additional words which are not duplicated
• Revise your sentence-based passphrase so that it contains an additional statement or idea.
• Revise your passphrase so that it contains additional adjectives and adverbs.

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.

Re:This is too simple to fix

[poopdeville]

Y'see, reusing a string does not significantly add entropy. That is why zip compression works.

Not quite. Entropy is a property of the probability distribution from which a sample (i.e., a password) is drawn. Whether or not reusing a string adds entropy depends on the underlying distribution.

Zip is designed to be most effective on text and other probability spaces where repetition is likely. Zip will not work so well when drawing upon a uniform distribution. On the contrapositive, using a repetition will increase entropy to the extent that a repetition is unlikely with respect to the underlying distribution.

Re:This is too simple to fix

[mysidia]

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

A single GPU cannot get as high as 1000 PBKDF-2 or SCRYPT hashes per second, let alone a billion.

Re:This is too simple to fix

[spazdor]

Entropy is a property of the probability distribution from which a sample (i.e., a password) is drawn. Whether or not reusing a string adds entropy depends on the underlying distribution.

The probability distribution is radically changed when you know one of someone's other passwords. Just like the probability of encountering the three-byte sequence "the" is radically changed after you've found it once in a string.

Re:This is too simple to fix

[zyzko]

or 6.25e14, that's 625 trillion. At a million cracking attemps per second,

that gives 19.8 years for an exhaustive search.

You are right in principle, but your cracking speed is way off - we are not talking millions of attempts per second but instead billions.

Re:This is too simple to fix

[The Archon V2.0]

A password vault is the only viable option.

That's OK, where I worked it was about as bad except we were forbidden to install a password vault. Everyone used post-it notes.

Where I was: 4 passwords.

1) Changed once every three months. Can't match the last 5 passwords, must have at least one upper case letter, one number, one punctuation mark.

2) Changed every 6 weeks. Can't contain a dictionary word or a previous password. Must contain one number or punctuation mark.

3) Changed once per month. Can't contain a dictionary word. Dictionary includes two-letter words, so "7@b!iT5{" failed as a password because of "iT".

4) Changed once per month. This was for the payroll system that only had to be logged into once per month.

Re:This is too simple to fix

[centuren]

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.

Reminds me of a quote I saw in a Slashdot signature about a decade ago (paraphrased here):

My password is my dog's name. My dog's name is "d^7O_JnT$2g-0p" and I change it every 30 days.

8 character passwords feels so 10 years ago. Using a password vault with a long key phrase, I keep about 4 random passwords, and 6 not random but extremely strong mixed character passwords memorised at any point in time (around 10, anyway). These are ones that stick in my mind, or I have to remember. With the advent of usable password vaults, there are upwards of a hundred random passwords much longer than 8 characters to keep track of. I change them in transition periods, where I introduce new passwords, shift old passwords, and generally have both old and new sets in play for different purposes at a time. I suppose it's staggered in tiers.

I have several financial online accounts, and I was shocked as the restrictions I found placed on many of them. I understand requiring users the use an uppercase letter and a number. I don't understand a bank of credit company rejecting passwords that have a hyphen or underscore, or are over 10 characters. Last time I changed my passwords there, the ones I had pre-generated were all rejected: I ended up having to create a new, much weaker password to guard over my finances. It was sufficiently annoying to use their customer feedback form, complaining about the seemingly unnecessary limitations on passwords. Their response thanked me for my interest in their security and informed me that my suggested to allow at least hyphens and underscores was forwarded to the appropriate department (which I suppose I'm satisfied with).

Re:This is too simple to fix

[Smallpond]

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

mon Dieu!

Re:This is too simple to fix

[Smallpond]

How about if you just allow any password and lock the account for 30 minutes after 3 failed tries? That's a technology that's been around for only, oh, 40 years. Does anybody actually break into accounts by guessing 100,000 passwords?

Re:This is too simple to fix

[Smallpond]

As an aside, I have no idea why I have to be an AC right now. I've logged in, but when I opened this article, I find myself in AC-land, and my preferences are gone. But then when I open other articles, I seem to remain logged in. ???

Maybe your password was too weak.

Re:This is too simple to fix

[Smallpond]

To be realistic, most people won't use more than about 3 words for a password, so let's say 5000^3 ~36 bits.

Whereas an 8-character password using upper + lower + digit + special is about 64^8 ~48 bits.

So the 8-character random password wins. A 4-word password would be equal.

Re:This is too simple to fix

[philip.paradis]

You're using an online password manager service, operated by someone else, on servers you don't control, to store login credentials for lots of other sites in one place? That seems like a disasterpiece waiting to happen.

Yes, I did review their site, including their security and privacy page. After digesting that information and reading over everything else on their site once more, I still see this is a pretty bad move. My primary concerns don't rest with the cryptographic algorithms being used, but relate much more to how those algorithms are implemented and how their infrastructure is controlled. That said, use whatever you like.

Re:This is too simple to fix

[mysidia]

A is a word, so I just use "a a a a" and it is as secure as any other 4 random words

Statistically, we can say that the probability you selected "a a a a" through a random process from all common words is microscopic.

Yeah, if you repeat the same word 3 times, or take all 4 words from the same page of a dictionary, that's easy to crack, if the attacker anticipates that you might do that.

Re:This is too simple to fix

[Bengie]

6-8 chars is too weak. You need 10-14 chars to be safe from brute-force. How about people like me who can't memorize random things because of some neurological disorder? Also, you should not have the same password for each account, so memorizing 20+ different random 10-14 char passwords gets hard.

Re:This is too simple to fix

[wallsg]

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

20? Welcome to the Internet and the World Wide Web! As you explore you'll find all sorts of exciting things. Have you discovered Youtube yet?

(BTW, it took me three tries to get the right password to log in and reply to this message...)

Re:This is too simple to fix

[wisnoskij]

"How about people like me who can't memorize random things because of some neurological disorder?"
Write it down and stick it in your wallet, unless you believe your wife is trying to steal your accounts then it is as safe there as in your brain.

Normal passwords cannot be brute forced because you are talking about online accounts that will lock after 5 tries.
6 is enough from all I have ever heard from experts.

And remember if the password lacks in randomness then that is just enough word for it can be cleverly guessed.
Changing your password to "p4ssword" instead of "das6%Gh9{" might be easier to remember and it might take the exact same amount of time to brute force but that does not make it safe.

Re:This is too simple to fix

[Vintermann]

Say I get access to your password from three different sites where you use that scheme. Suddenly, the fact that they are 8-digit stings contributes virtually nothing to security.

I like Cameron Morris' tool. I can feed it passwords like ";4angestogungi" and it spots sense in them that make them easier to memorize; in this case "changes to fungi".

Re:This is too simple to fix

[AvitarX]

Actually, I think the common occurrences lately have been getting dumps of non-salted (but hashed) databases, and then running a rainbow tables attack.

This is a completely different problem, as generally tables don't go beyond 14 places. A 30 character very simple password (but outside of a dictionary) will survive if only hashes are found, while a 8 character completely random password will be found.

4 8 digit sequences are unlikely to be cracked in the common occurrence of large password thefts (e.g. gawker).

Re:This is too simple to fix

[AvitarX]

6-8 character passwords quickly fall if an unsalted hash is stolen (see rainbow tables).

A long, but less random password is much safer.

Re:This is too simple to fix

[wisnoskij]

From my understanding of hashes and rainbow tables I cannot say that that makes too much sense.
But I cannot say I am an expert.

What I would question is how easy it is to get an unsalted hash in the first place.

Re:This is too simple to fix

[AvitarX]

as easy as getting a plain text password I would say, and both are essentially not brute forcible.

From Wikipedia, emphasis mine:

Rainbow tables and other precomputation attacks do not work against passwords that contain symbols outside the range presupposed, or that are longer than those precomputed by the attacker. However tables can be generated that take into account common ways in which users attempt to choose more secure passwords, such as adding a number or special character. Because of the sizable investment in computing processing, rainbow tables beyond fourteen places in length are not yet common. So, choosing a password that is longer than fourteen characters may force an attacker to resort to brute-force methods

Essentially, if a database falls (through SQL injection), then there is a good shot your 6-8 character password will fall against an exhaustive rainbow table (if it is unsalted). If it is salted, then both are secure, and if it's plain text both fail.

Re:This is too simple to fix

[wisnoskij]

But if a website is already that insecure that they keep unsalted passwords in their insecure database then their is not much you can do. Maybe they keep your passwords as pure text.

Hashes have to be salted if you want any amount of security.

Re:This is too simple to fix

[AvitarX]

that's not true though, according to what actually happened when gawker's unsalted hashes were stolen, and according to the Wikipedia article about rainbow tables.

An unsalted 8 character password is essentially as weak as a plain text one, while an unsalted 30 character one is essentially as strong as a salted one.

Re:This is too simple to fix

[ClioCJS]

what makes you think i type my "garbled string" (which is actually a patterned rhythm used for 20 yrs, but moved around on the keyboard) any slower than my normal 100WPM? Conversely, what makes you think I can type English words any faster than my normal 100WPM?

Re:This is too simple to fix

[poopdeville]

No, the probability distribution is fixed at the time it is sampled.

For example, if I generate a random password from a uniform distribution of letters, I can end up with a "the" in the middle of it. That does not make it more likely that any given string will follow the "the". As I said, the entropy is a property of the distribution from which a password is drawn.

Consider the sequence of values:

"the aaa"
"the aab" ...
"the car" ...
"the zzz"

What is the probability that "car" is chosen from this list, given that it is uniformly distributed? It is 1 in 26^3, assuming the alphabet is entirely lowercase; not 1 in the number of three letter nouns and adjectives. For the latter to hold, we would have to be drawing uniformly from:

"the ace"
"the bat" ...
"the car" ...
"the red"
etc.

You seem to be confusing the underlying probability distribution from which a password is sampled with some kind of conditional probability relating the occurrence of a string to the underlying probability distribution. But that is a non-issue. The attacker doesn't have even partial information with which to compute Bayesian statistics. He doesn't know a priori that "the" is a part of your password, and he doesn't know which underlying probability distribution you chose to use.

Re:This is too simple to fix

[spazdor]

The attacker doesn't have even partial information with which to compute Bayesian statistics.

Did you miss the part where I said

when you know one of someone's other passwords

?

We are talking about somebody, perhaps the administrators of 2 other sites you use in collusion, who knows at least one of your previous password choices. Just like the zip compressor knows the content of the preceding part of the string.

The reason password reuse is a problem, really boils down to the fact that the concatenation of any two of your passwords should contain significantly more entropy than either password alone. Direct password reuse reuse fails this test horribly; reordering it in large chunks is better, but not by much.

Re:This is too simple to fix

[Patman64]

Clearly you haven't gotten the Nvidia memo. GPUs are magic. They can do anything and everything, if only programmers weren't so darned stupid.

Re:This is too simple to fix

[Ghostworks]

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.

You could just use a kernel password and tag on a date: MyPass112011, MyPass122011, MyPass0112012,.... That's what most of the bank officers do when they're forced to do that same thing.

Re:This is too simple to fix

[Tom]

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

You are wrong. I actually did the math on this for a paper, and the order-of-magnitude in complexity is 10^16 - comparable with what your average password policy provides in theory. The problem being that for the reasons outlined in xkcd, my paper and many other places by now, the actual complexity of most policy-compliant passwords is actually on the order-of-magnitude of 10^7 - while even a worst-case estimate for the xkcd-style password still provides 10^12.

Can't link to the paper because it's only available in print (it's in ISBN 9-783844-806885).

Re:This is too simple to fix

[Tom]

You are thinking "Internet" and "e-mail", when the more likely scenario for a setup like this is "corporate network" and "Exchange".

Where, among other things, you wouldn't change your password on a website.

Re:This is too simple to fix

[Tom]

Really?

Are you saying that out of "gut feeling" (you know, the same thing that tells you the earth is flat), or have you actually clocked yourself typing in "12ol3jkh!!asrdfw9g8" or "^TFGY78UH" and compare it to typing "This chicken tastes like shit!" ?

12ol3jkh!!asrdfw9g8 - 9 seconds
^TFGY78UH - 4.8 seconds
This chicken tastes like shit! - 3.4 seconds

Those are my times. I'm sure they'd come down if I would type this every day as a password. I don't know if they would come down the same, but even the garbage one were to improve twice as fast, the first one will never be faster to type than the last one. Even if it came down three times as fast (unlikely) with practice, it wouldn't, considering real-world restrictions on typing speed.

Re:This is too simple to fix

[allo]

of course it would.
just choose a path like this:

nouns
verbs
attributes
noun verb
attribute know verb
[...]

it will eventually find the right combination of wordlists as pattern and then the right entries in the wordlists to find "this chicken tastes like shit"

Re:This is too simple to fix

[allo]

as long as your password generator algorithm finds phrases, which are easier to memorize, it drops entropy, so a cracking-algorithm can use these propertys to shorten the wordlist. so it will not drop this-chicken-tastes-like-shit and not drop "this chicken tastes like shit", but maybe it will drop some combination of spaces/dashes, because it knows, that the generator algorithm knows, that human beings are having more problems to memorize irregular combinations of space/dash delimited words than just memorizing words with all the same delimiter.

of course you can say, the cracker does not know my generator algorithm, but even a cracker which assumes the generator as a black box, can identify by itself which words are more likely to be generated than others and order the wordlist in a way, that the more often generated words are tested first.

Re:This is too simple to fix

[Sancho]

I don't know Exchange, but unless the e-mail actually triggers the Outlook dialog which prompts for the password, I don't think it matters. Users will reply with their password to phishing mails. Setting up a system where you are e-mailed when you've screwed up isn't going to help that--it's just going to make spear phishing more viable.

Re:This is too simple to fix

[Tom]

GP was talking about system/network passwords, not some website.

The e-mail he mentions most likely contains some instructions along the lines of "open up the system preferences, go to ..."

Re:This is too simple to fix

[Sancho]

GP was talking about system/network passwords, not some website.

I don't think that's clear, but at this point arguing further is pointless.

Re:This is too simple to fix

[Drishmung]

It was indeed "corporate network"; it was not Exchange. It was years ago, and the users in question were logged on to Unix systems.

Re:This is too simple to fix

[trdrstv]

Set login restrictions so a student can only log into specific machines. If that's too much of a hassle (logistically not technically) there are tools to restrict the number of concurrent log ons they are allowed (at least in Active Directory) and you can set that to 1. It also helps if your apps use integrated authentication because if they share their password and someone else logs in as them, not only can that new person not do their work, the person who gave up their password can't log in and do their own work.

Re:This is too simple to fix

[trdrstv]

or 6.25e14, that's 625 trillion. At a million cracking attemps per second,

that gives 19.8 years for an exhaustive search.

You are right in principle, but your cracking speed is way off - we are not talking millions of attempts per second but instead billions.

Entirely academic. What IT Admin with a brain allows infinite failed attempts on an account ? Even if you could hit the server with BILLIONS of attempts in a second, where is the value when my system will lock that account (and requires a human to manually unlock it) after 5 failed attempts ?

Re:This is too simple to fix

[nmr_andrew]

There are on the order of several dozen intuitive ways to combine 3 strings of 8 characters. So yes, there are about as many generatable passwords in your method as there are possible values for 1 character.

While what you say is probably true (I'm too lazy to do the math, but it's on the right order), it assumes that you already know the 8 character strings that are being combined. If you're trying to break into a buddy's account, know he uses such a scheme, etc. that's fine. But if you're trying to crack someone's account randomly, the password is for all practical purposes 24 characters long.

Or am I missing something?

Re:This is too simple to fix

[Cramer]

through a random process

That's the key... Humans. Aren't. Random. Knowing a little about the person can often significantly reduce your search.

Re:This is too simple to fix

[spazdor]

Yeah, here I'm talking specifically about someone who already knows something about your password system.

Someone who administrates one other site for which you generated a password by this method would have to have asked some questions (or, say, overheard you talking about your password system on Slashdot) in order to know in the first place that the password should be decomposed into three separate tokens and then recombined, in any of n possible ways - as i suggested, probably several dozen.

Once they know this, however, they have n possible candidates for the original 3 strings, and n different ways of recombining them, yielding an effective keyspace of n^2. Pretty paltry.

And two (or more) site administrators working in collusion, having access to two of your passwords, wouldn't even need to overhear you explaining your password system in order to attack it; the system and your original 3 strings would be nearly self-evident from looking at the passwords themselves.

Re:This is too simple to fix

[SuricouRaven]

That's what we do. Disable the account immediatly for security reasons, and the make sure the procedure to have it reenabled has far more red tape than it really needs. It takes at least a few hours, maybe a day, to talk to the required inaccessible people.

Re:This is too simple to fix

[rjstanford]

The characters are "words in a dictionary" not "glyphs on a keyboard".

But when cracking a password, you look at "words morons on the internet use a lot" and there are probably closer to 5000 of those (compared to 50000 regular words). Combine with noun / verb / article classes and weight words with frequency and you can narrow that down to a LOT less in practice.

Pass phrases are dumb.

Of course, even if you got down from 5000 to just 500 (unlikely), that's still vastly more than the number of letters commonly used... you're looking at 500^5 instead of 26^5. Then add in apostrophes, Capitals, abbr.s, and so on...

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

[del_diablo]

Well, a "common" dictionary is still 200-300 words. And you can also use the name of a pet. So that is a X variable that is fairly large. So basically we have 300*300*300*300*X, and X is most likely larger than 500. Its still a lot of passwords, and then we have the spelling mistakes, writing the words as their litteraly are spoken, and a lot more. Just replacing e with 3, i or l wih 1 and 0 with o is just more noise to the pattern.
Basically: XKCDs multiple word scheme is secure enough if its long enough. Just like normal passwords.

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

[jmottram08]

And then you remove the reason to use pass phrases to begin with. Read the XKCD linked.

Re:Wrong

[sexconker]

EFWWH!Bypc,IaCP!

1 bitcoin to anyone who can tell me what that means.

Re:Wrong

[Belial6]

Add to that the fact that you wouldn't even need to use the persons entire vocabulary.

Re:Wrong

[gman003]

It's best if the words are truly* random. Don't come up with them yourself - flip through a dictionary and pick random long-enough words, or better yet, use a computer program. Most estimates place the number of words in the English language at about a million. Even if you conservatively assume only 10% are long enough to be used in a password, four fully random words comes out to be 100,000,000,000,000,000,000 potential passwords (10^20), and if you throw in randomly capitalizing first letters, it goes up to 1,600,000,000,000,000,000,000 (20^20).

This probably spikes even faster if you use multiple languages, although that probably only words for people fluent in multiple languages. Still, a bilingual 4-word password would easily be in the 10^22 range, possibly much higher if which languages those are are not known.

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

[justthinkit]

On one camping trip we met someone whose pet had the same name as ours, and it turned out they had a second pet (cat) at home that had the same name as one of ours, also as home.
.

Pet names are much more predictable than other categories of names, except maybe trees and such.

Re:Wrong

[swillden]

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

Both facts that Randall Munroe considered when he drew the XKCD strip. He claimed 44 bits of entropy for the four-word passphrase. If you work that backward it's not hard to calculate that he was assuming four tokens selected at random from a dictionary of 2000 entries. That's an entirely reasonable dictionary size, and 44 bits is a respectable amount of entropy.

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

[rolfwind]

In an era of "Secret Questions" and facebook, we really don't need to worry about passwords. Those SQs are the bigger problem. If the answers aren't on your facebook profile, many of them can be socially engineered out of friends or the like. (For example, you're tagged in someone else's picture. They're a childhood friend. An easy path one way or another to discover the HS you went to, a SQ staple.)

It pissed me off to no end that Apple recently implemented this.

Re:Wrong

[JWSmythe]

    We adopted two cats several months ago. One of them acted oddly, so we were going to name it "random()". We'd just say "random", but write it for the vet the other way. We agreed on a more unique and fitting name for it. Cathazoid315 was also a consideration.

    Oddly enough, Cathazoid315 shows as follows in the Passfault tool.

Time to crack: 1 decade, 4 years
Total Passwords in Pattern: 436 Trillion
Misspell US Cities 46% of total strength
Substitute Spanish 54%
Random Characters (numbers) 0%

    Where exactly in the US is Cathazoid?

    I still prefer nonsensical and horribly misspelled words and phrases, to the point that even when written they don't look like their origin words.

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

[stephathome]

This kind of thing is why I often use someone else's information for "Secret Question" answers. Real, fictional, all that matters is that I know whose answer I used on which site.

Re:Wrong

[0123456]

Fortunately my mother's maiden name is v6g1sH6Ynr.

Re:Wrong

[Dopefish_1]

In an era of "Secret Questions" and facebook, we really don't need to worry about passwords. Those SQs are the bigger problem

This. I will occasionally put in long strings of random characters for websites that ask these questions, and just accept that if I ever legitimately forget my password, the account is gone forever.

Re:Wrong

[worf_mo]

EFWWH!Bypc,IaCP!

1 bitcoin to anyone who can tell me what that means.

Every Fine Weasel Washing Hands! Buy your pills cheap, I advice Contingency Plan!

Too easy!

Re:Wrong

[colinrichardday]

With 7776 tokens

What? Slashdotters don't have D20s?

Re:Wrong

[sexconker]

We have a winrar!

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.

Re:Wrong

[dbitter1]

Sadly, some banks use some type of "close" algorithm (soundex?) that lets you get away with a somewhat inexact answer (one of mine is one, sigh). So although I totally praise your style (I do this too) you are SOL if their algorithm chokes on the first non-alpha character, and "v#()*(#(#(#" also becomes acceptable, and you have no further guards on setting up EFT/ACH transfers...

These stupid, asinine people designing this security theater are replacing your secure password with a totally insecure one.

Re:Wrong

[RulerOf]

Fortunately my mother's maiden name is v6g1sH6Ynr.

I think our mothers must have the same ethnic background. A similarly-named company also produced my first car.

Wait a minute.... That's also where I met my spouse!

Re:Wrong

[swillden]

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.

Granted that 44 bits isn't enough if the password hashing implementation sucks. An implementation that uses, say, PBKDF2 with HMAC_SHA1 as the PRF would increase the cracking time by about four or five orders of magnitude, making it safe against anyone who isn't willing to buy thousands of GPUs (keeping in mind that Amazon EC2 and similar means that buying thousands of GPUs isn't as costly as it once was -- renting, say, 100K GPUs for a few weeks would cost a lot of money, but

So, if you're concerned about bad password hashers, add a fifth word and another 11 bits of entropy. Assuming you can. The sorts of systems with lousy password hashers tend to be the same systems that don't allow you to use long passphrases. On those, you have to fall back on maximizing your character set. Of course, many crappy systems restrict that as well.

Re:Wrong

[The Raven]

This is rather late, so only you will see it. But please beware using sentences. For example, "Stupid bitch" might as well be one word, since bitch often follows Stupid. Same with "never again". So you transform a password from the equivalent of 5 words to 3 by making it meaningful. That is the exact issue that xkcd was specifically seeking to avoid by using random words, not meaningful ones.

Re:Wrong

[robsku]

I have never understood how these insecure online banking systems I hear about now and then are even legal in (some) 1st world countries - this would simply not do in Finland. In my bank (Nordea) you need login ID (long string of numbers) and 4 digit single use "pin code" (the bank sends you a new sheet when your close to end) - and even if you get my login codes (by tricking me to fake bank website?) you can use them only once - and then you cant get past when it asks for a random number from a set of 4 digit "confirmation codes".

Re:Wrong

[Millennium]

You're right that words become tokens, but most people's vocabulary is a lot larger than the number of printable ASCII characters. This is why the scheme stands up to the problem you mention. Even with a bare-bones vocabulary of 800 words, a five-word phrase is stronger than an eight-character string of alphanumerics. Most people's vocabulary is larger than that.

Re:Wrong

[rjstanford]

So what? The question is not whether or not it takes a certain amount of time to brute-force 44 bits of entropy. The question is whether those 44 bits of entropy are more or less (hint: more) than the entropy of most "secure looking" passwords.

another password revealed

[ozduo]

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

Re:another password revealed

[theshowmecanuck]

Well I thought this was funny as hell.

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

[alcourt]

Any password policy that permits an end user to have a password as sufficient authentication is broken.

Go to strong authentication, and be done with the whole "one memorized token alone is of value" concept.

Re:Terrible password policies

[King_TJ]

Yeah... especially with online banking, it seems as though someone had a very poor idea for password security that got foisted upon ALL the major online banking sites - just when some were starting to come up with much better and more practical solutions.

I remember one of my banks started playing around with the idea of having you select several images from a gallery, in a specific order, as a secondary part of your login. You'd still sign in with a password you selected, but there weren't many limitations on it (other than it having to be longer than, I think, 4 or 5 characters), but you also had to match up the image sequence.

I thought that was a pretty good way to enhance password security without people resorting to using difficult to recall passwords that they'd wind up writing down on post-it notes, or constantly forgetting and locking themselves out of the site.

But that quickly vanished with a website revamp -- replaced with the same maddening stuff I've seen all the banking sites doing recently. (Basically, they ask you to select from a few security questions and key in responses, which you have to randomly answer in the future. They're always really poor questions like, "What was the name of your first car?" -- where you're likely to say something like the make and model initially. Then later, when asked, you forget if you keyed in just the make, the model, make and model using all lower-case letters, make and model capitalizing both words, or what? And yep -- locked out again! And the password itself always has some requirement of having numbers and a capital letter in it, and being more than 8 characters -- ensuring you'll wind up with something you can't remember.)

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

[CodeBuster]

Whenever I'm setting up a system, I generally allow seven (7) tries before locking out the user for at least 10 but not more than 20 minutes (10 + random 20). During the lockout period even the correct password will not log in and failed attempts provide no information to an attacker concerning the reason for or nature of the failure to login. With a system like this, even basic 7 character passwords with just letters and numbers provide a decent level of security. A password protected system should always be combined with an automatic lockout policy with automatic reset; it increases the strength of the login considerably by rendering increased attacker computing power useless. The only real downside to a system like this is the potential for DDOS, but even that can be mitigated by allowing only 100 or so attempts per hour from a particular IP address, on top of the regular lockout period, before automatically dropping traffic from that IP address for a couple of hours. These policies should turn away all but the most determined and best equipped attackers. The botnet DDOS might still prevent people from logging in, but if your site comes under an attack like that you've probably got bigger problems than users who cannot log in.

Re:Terrible password policies

[thsths]

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

Did they also ban notepads and post-its? Because that is the obvious alternative then...

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.

Re:Terrible password policies

[Tom]

Any password policy that basically forces you to write down your password somewhere is broken

That's ideology, not wisdom.

In fact, there are many real-world cases where the policy itself requires that the password is written down. For example, a company I used to work for had only a small number of admins for each system (a total of about a dozen, usually in pairs for the main systems). The risk that both of them were lost to accidents, sudden leaving or whatever was something the company didn't want to bear, so all the root passwords were written down, sealed in envelopes and put into a safe.

It was a good policy, and it actually saved us more than once during emergencies where the admins were not reachable, something had to be done right now, and someone with sufficient skill (but who was usually responsible for a different system) was on hand.

The alternative would've been to give all passwords to all admins to memorize, but we all know how well that memorizing part goes for password you use maybe(!) once a year.

Re:Terrible password policies

[Yvanhoe]

I love how my bank makes me enter a numerical code through a keypad rendered with image buttons that appear in a randomized order. They must somehow think that this must prevent some kind of automated attacks. Except that one day I loaded it with no script, and instead of the keypad, I had a regular textarea to enter my code through the keyboard. It worked like a charm.

Security theater all along. The same bank is really confused about security, allowing some things to be done through mail or phone, disallowing some other innocent things for "security reason". Why is it that banking security became the joke that it is today ? Is there no one trying to crack them anymore ?

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

[DragonWriter]

why is it all so difficult to come up with some scheme to secure internet accessible resources.

Its not.

Its hard to come up with a scheme to do all of the following simultaneously:
* Secure access to internet accessible resources from unauthorized use,
* Permit access to internet accessible resources to authorized use,
* Have a low per-user cost to implement and support
* Be convenient for common users

Can't it be as simple as probing me for dynamic info that only I would know?

If its dynamic (rather than static, in which case its effectively just a password with a -- possibly visual -- hint), and only you know it, how is the system going to get the correct answer in order to probe you for it?

Re:What puzzles me...

[Daniel_Staal]

If they know it, it's not something 'only you would know' (or it's a password, effectively). Family or coworker snapshots can be defeated with a bit of time on Facebook. Etc. The article above seems to think switching to a physical token is a solution - effectively switching from a combination lock to a keyed one. Which works in a controlled, corporate environment.

But the problem is fairly complex: You need to come up with a simple, secure, easily implemented, quick way to distinguish a human from a machine, and one human from another. Oh, and it needs to be accessible: your visual idea only works if the person you are trying to verify isn't blind. (Even temporarily.) Security in general has been a problem for as far back as at least the Romans, if not further; there's a lot of value in breaking the other side's security, and a lot of value in not having them break yours. (Heck, I've seen tribal huts using the traditional design that had locks on their doors, though they don't look like what you'd think of as locks.)

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:What puzzles me...

[nonsequitor]

Just remember 1 really strong password. Then change your password 9 times every 90 days to keep using it. There's no policy rule that forbids a password that was used in the last 90 days, so obviously IT is okay with this approach to security.

Re:What puzzles me...

[Tom]

There are trials on that, most of them aren't too successful.

The problem is that higher-order pattern recognition is fantastic in humans and sucks in computers. How many pieces of software do you know that I can show a picture and get back a list of items in it? How long would a human take for the task? You're right if your answer was "depends on how fast he can write", because that is the part that takes time, object recognition is almost instantaneous, unless the image is very cluttered.

And it's like that with pretty much everything else. When you boil down the info to something the computer can understand, e.g. giving it a set of pictures and a set of decriptive terms to go with them, your entropy isn't the complexity of the pictures anymore, it's the complexity of the list of terms, i.e. practically nothing.

Dynamic methods suffer from expression and natural language recognition. If I as a human want to know if you are really you, I could ask you about last wednesday at the pub, and your answer would give me a strong indication if you are (or at least know a lot of personal details). A computer would need to comprehend what you say, and natural language recognition isn't all that great, still. Because there are at least 100,000 ways in which you could describe what happened at the pub, leaving out these or those details, using those words or these, etc.

Re:What puzzles me...

[panda]

It's very simple. Issue certificates to your users. Only let them into your site if their browser presents certificates signed by you. You can use fields in the certifcate to identify the user of your site.

Certificate management isn't that hard. Most private keys are protected by passwords, but still, I think it is a damned sight better than just username/password.

Re:What puzzles me...

[jbwolfe]

Naturally its an overreach to suggest at this point in the evolution of AI that we can emulate the abilities of the human mind in this regard, but why are we not yet able to tap the advantages computers have and yet perform a more human like approach to passwords. My point is that just like in advances in particle physics and biology these days, someone at the university level must be looking at ways to better this archaic system of password authentication.

For example, policy where I work disallows repeating or sequential characters (even as part of a complex password)- they've just reduced the pool of available passwords in fear of a dictionary attack. They're solving the wrong problem. When will we progress beyond this?

Re:What puzzles me...

[trdrstv]

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

Why would you have to write it down ? Those requirements are trivial.

Our passwords change every 30 days, must be 8+ characters long, use 3 of the 4 character types ( UPPER, lower case, Numbers and special characters) you can't use the last 24 and they have a minimum password age of 1 day (so you can't cycle through them and go back to the old one) and you know what? It'sT SIMPLE to come up with a password that fits those requirements and remember them, you just need a pneumonic device.

Stuff like: "Summer2012" , "It'sFriday" , "FreeFood!" "Grads2012" , "WTFjusthappened?" or "FuckThisShit!" all fit complexity requirements and are pretty simple to remember.

Some more fun passphrases

[Anonymous Coward]

sandra bullock upload virus
good luck with that i have a zero balance
cowboy neal is the joke reply

You'll have to imagine there are no spaces, because it won't pass the /. filters as a concatenated string.

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.

We do this at work

[smartin]

i.e. 7 characters one must be a non-character or capital.
The result is that people like me chose passwords that a keyboard patterns that anyone could guess if they watched me type it.

Re:We do this at work

[leenks]

Awesome paper on password patterns - http://www.usafa.edu/df/dfe/dfer/centers/accr/docs/schweitzer2009a.pdf

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

[del_diablo]

Getting a new account and transfering everything is always a mess. Its hard to do. Human nature at its best.

Re:The main problem is...

[nzac]

Did you understand the XKCD comic?
the whole idea is random. Those similar looking numeric substitutions are binary at best adding 13 bits at best.
It's hard to remember the ones you chose and if you chose all of them you would only add 1 bit.

Re:The main problem is...

[maglor_83]

Mine used to be like that.

Exactly 6 characters.
First 2 must be alpha.
Last 4 at least 2 consecutive digits.
No special characters.

Fortunately they've changed that now.

Re:The main problem is...

[Mashiki]

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

He could live in Canada. All of our banks use this, an example:

When changing your password, please remember that it must be between 5 and 8 characters in length and should contain both letters and numbers. Special characters (e.g. #, &, @) must not be used as they will not be accepted by the system. Passwords consisting of all letters or all numbers are not recommended. Although *BLANK BANK* does not require you to change your password, we recommend that for security purposes you change your password every 90 days.

I still don't know of any bank in Canada that offers token's. Hell my blizzard account does, so does that mean my blizzard account is worth more than the money I have sitting in the bank?

Re:The main problem is...

[pankkake]

My bank requires 6 numbers, no more, no less.
If you make a certain number of errors, the account will be locked. So if someone tries to brute-force your account, you have to call the bank to activate it again.

It's probably the least secure website I use.

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

[wisnoskij]

It is 6 max because you should never need a longer password for a website.
After a small handful of wrong tries your account will be locked, so unless your are an idiot and you password can be correctly guessed in 5 tries, then 6 is actually far more characters then you need.
the good thing about enforcing a small password is that it at least prevents some stupid passwords, and can in many cases prevent using other site's passwords. So you could say that policy could make it statistically safer.

Re:The main problem is...

[wisnoskij]

What is stupid is when you encounter ridiculously high minimum lengths. Once, for some stupid forum, I had to have a minimum length of 22 characters.

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

[shadowsurfr1]

Seconded. At my workplace, we have a maximum of 8 chars with a limited charset. And we have to change them every 90 days which is silly and just encourages a lot of people to write them down.

Re:The main problem is...

[__aaqvdr516]

If your bank is like my bank it has triple factor authentication, even with the password length restriction.

Account number, PIN, and password.

Re:The main problem is...

[ToasterMonkey]

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.

Switch banks!!!! Or at least put your direct deposit in a different bank. One thing the world is not short on is banks of various sizes. Shop around, they should work for your money.

IMHO, there seems to be as many bank branches as there are fast food joints in the U.S. There's little reason to keep your money parked in a particular bank.

Re:The main problem is...

[__aaltlg1547]

If they lose your money, they'll just overcharge their other customers to make up their loss.

No problem.

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

[nzac]

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

My understanding of leet speak is its a mapping of a latin character to one of many alternative representations, that you choose to use or not.
In his case he chose a subset of the leet alphabet which allows for a one to one mapping of a letter to a number which he can choose to do or not. He can do this at random at a 50/50 split. If there is some commonly know way chose to use the leet char then this is easier to remember but only requires a trivially small amount of guesses to guess.
I count 23 number leetable letters so if you do it randomly (he is not even close to random, he has chosen characters that make it look good) you add 23 bits to the password this gives good security with 67 bits but requires you to remember 23+4 choices in sequence (some people can do this easy others not a hope to get it right first time after not having used it for a couple of weeks). Alternatively those bits could be added by adding two extra words or by using a much smaller number of proper random substitutions.
Leeting adds complexity but is insanely hard to remember and if not done randomly you probably do it similar to how everyone else did it making it easier than binary choices to guess. In his case its making a choice of one out of a set of 2 (2^1), which according to the comic is a terrible (the worst) way to do it. Randal advocates randomly choosing 1 from a set to 2^11 which is not exponentially harder to remember but exponentially harder to guess.

Re:The main problem is...

[stephanruby]

Why would there ever be a reason to enforce such a small maximum length?

A little empathy please. It's not so easy to memorize hundreds of thousands of such passwords for your online customers. And I'm shocked that those little men sitting inside those ATM machines can even do something like that at all.

Re:The main problem is...

[sco08y]

+4 Insightful? Because this is something you easily find out before registering an account at a new bank.

I registered a free checking account at a bank, found that they had shitty security, and I closed it the next day. They gave me a cashier's check for the balance, so my total cost was zero.

The bank I'm using, I had the account open for a month before I was reasonably satisfied that they had their shit together, and I then transferred my direct deposit to them. This stuff isn't all that hard.

Re:The main problem is...

[thsths]

6 characters is perfectly fine if they only give you three attempts. In fact, most problems with passwords go away if you can limit the number of attempts - that means keeping the hash secret.

Most of the discussion revolves around the idea that we need a password complex enough to defeat decrypting it even if the hash is leaked. That is a very hard solution, and so far there is no plausible solution to it. The only good answer is two factor authentication.

Re:The main problem is...

[dkf]

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.

No, that's just a different class of attack. You've got to protect against both (and many others besides).

Re:The main problem is...

[jimicus]

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.

They shouldn't. They should have expired the password and prompted the user for a new one immediately that happened.

Rationale: If the user made a typo after the 11th character (based on your 10-character-max example), you've just gone and stored a password that's subtly different from what the user thinks it is.

Re:The main problem is...

[Mashiki]

So what you're saying is, this is the new golden age of bank robberies and no one has really figured it out yet.

Re:The main problem is...

[youngatheart]

I thought of that flaw and as an experienced programmer, I would have prompted the user to re-enter and then verify again the entered password. I didn't add that to my comment because it was already suffering from "too long, didn't read" syndrome.

Your solution of expiring the password immediately could be bad, very bad. Instead of having a few callers per day complaining about the problem, you would instantly have hundreds and maybe thousands of additional callers.

That is a simplification though, If you were my boss and said "no, I don't like it, I want them to have to enter a new password" then I would have done it differently. I would have built in a graduated delay so that on day 1, all usernames beginning with the letter 'A' were prompted for a new password, with 'B' on day 2 and so on. If I felt like a month of higher call volume would exceed the metrics of the call center, I would have switched it to 'A[A-M]' and so on.

Your concern is valid, but you are showing exactly the limited foresight that young and inexpensive programmers are dangerous for. Granted, had I been willing to add a few more words to my explanation, you might not have made that error, but a wise programmer wouldn't have made it in the first place.

Don't think that my criticism of your solution is a critique of your intelligence however. I consider myself to be an intelligent person and ten years ago, I would have made the same mistake.

Re:The main problem is...

[jimicus]

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.

Most half-decent banking systems that include a OTP require that OTP for carrying out transactions,

Re:The main problem is...

[robsku]

We have account number + one time PIN sheet, which you get by snail mail and the account number is not printed on the same sheet. New sheet of codes is mailed after you have used up 2/3 of the codes, after which the rest will still work until you use the 1st one from new sheet instead.

Also, to protect you from phishing attempts or accidentally leaving browser open and not logging out, there is a second smaller set of PIN's on the sheet and actions you perform will need to be confirmed by entering the confirmation code assigned to random alphabet (A-Z). So a mediocre phishing site to collect login credentials will be pretty much useless and what they would have to do is to program the site so well that it seems to work normally, it would need to actually log in to your account on the server side and perform actions, then hope that you make a transaction too so that they can ask the confirmation code they are being asked for - and if you don't do transactions or other things needing confirmation, then not only will they fail to get anything but also the next time you get to the real bank page you will see that something was attempted as there is a request for confirming something you did not do.

To be honest, almost all stories I've heard of online banking in most other countries gets me baffled - I mean, how is it even possible that even in many 1st world countries this kind of disregard for safety is even legal, let alone also more like a rule than a horrible exception. Seeing that banks, off all things, act so ignorantly when it's well known how "secure" it is to trust the end user to not do something stupid or not have malicious software collecting login credentials, etc. I'm glad that at least here in Finland there is actually some rules that makes it mandatory for online banks here to provide something actually secure - though it's something I grew up to expect banks would obviously *want* to invest in anyway, seeing how things are in various other countries I don't know whether they actually would if there were no rules for it... I'd like to think that they still would, but I really don't know anymore.

Re:The main problem is...

[Gyorg_Lavode]

If a system has a password maximum length, it probably means it's neither hashing nor salting your password since the main reason to minimize length would be to fit it into a database field. Food for thought.

Typos

[Xian97]

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.

Re:Typos

[gtbritishskull]

I feel that I am more likely to mistype weird capitalizations, numbers, and symbols than a much longer string of words with (possibly) normal punctuation.

Re:Typos

[justthinkit]

Type it somewhere else where you can see it, copy it to the clipboard, paste/use it, copy something else to the clipboard.

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.

Re:Typos

[roc97007]

What the heck are you talking about?

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.

Re:testing the password

[del_diablo]

Its not a good calculator either:
Compare a scandinavia sentence with a number in it with Same text with the number written. This clearly shows us that the XKCD scheme is more than good enough. And we can still add in things like spaces, underscores instead of spaces, and replacing letters with numbers.

Re:XKCD

[fiziko]

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.

True, but humans can download large electronic dictionaries and use a computer to pick, say, 4-8 words at random. Since that XKCD came out, I've used a non-random 35 character string followed by one of my old 8 character gobbledegook passwords as a new 43 character password that I can remember. Takes time to type, but I figure it's the "best of both worlds" for security. Unfortunately, a lot of websites I've tried to do this with have an upper limit on password length that is shorter than this.

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

[spetey]

If there were only some competing Micro$oft project, and a way to support the upstart with bitcoins.

Re:Wow...

[DerekLyons]

Yeah, but he forgot to bash Microsoft and to genuflect in the direction of Cupertino and Mountain View...

Re:testing the password

[JonySuede]

they are conflicted with themselves :
security:6 weak
entropy: 117.5 bits
but try that one:
http://www.wolframalpha.com/input/?i=password+strength+Correct_house_battery_staple :
security: 151 very strong
entropy: 185.4 bits

Re:testing the password

[JonySuede]

there was a dot that disappears at the end of the url

Re:Passwords DO suck

[hawguy]

...It's too bad there's no way for two hosts to authenticate on a pre-shared key system with a public half and private half for each key, so bob and alice trade public keys and can communicate safely even if eve has both public keys....

I'm not sure what problem you think you're solving with public key cryptography, but it still doesn't remove the password problem. Most people will still want their key to be protected by a passphrase (or some other method that keeps anyone with access to the computer from using it), so passwords won't go away even if everyone uses cryptographic keys to identify themselves.

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.

Fix what?

[OldHawk777]

Pwds will always be an easy security bad idea, because by the time a new pwd sec-theme is common cracks have been emplace for about five years.

We need to get pass crazy/silly pwds to non-human dependent security. It will cost a little more, but increased productivity and better security will save oodles.

Pwds are in the trench of the Maginot-line of security, stop wasting time and money, get to bio-PKI and beyond. Easy (to manage/implement or cheap) security is bad security physically/virtually.

password managers make it easy

[w.hamra1987]

they sure do make it a lot easier, with some downsides as well. i use keepassx on *nix, and keep a portable keepass on my USB thumb drive for windows computer. all my passwords are store in it, all are 25 characters, with around 200 bits of entropy each. the only thing to worry about, is the master password, which was created using keepassx's password generator as well. as long as i remember to exit it before leaving, or at least locking the computer, there's not much to worry about. all passwords different, all strong, and auto-type makes things very easy. the downside is... you dont really know any of your passwords, and become reliant on the program. that's why i keep at least 2 complex passwords committed to memory and use them for common stuff, like my email. it's quite embarrassing to sit by your university project partner, be asked to login to the university website, put hand in pocket, realize you forgot the thumbdrive home, and exclaim "i don't know my uni password at the moment".

Re:password managers make it easy

[real-modo]

There are KeePass apps for Android and iOS.* I use apps on both, as well as KeePassX and Windows KeePass, all with the one password file stored on DropBox. If I don't "know" my passwords, it's because I don't need them. (No, Virginia; if the keepass password file is insecure on DropBox, it's nearly as insecure on one of my PCs or a thumb drive, and a lot less usable.)

(Hint: in DropBox for Android and iOS, be sure to mark the KeePass password file as a "favorite", so it is stored on the phone/device, and not merely downloaded when you try to open it.)

* For BlackBerry too; Symbian, bada, Windows Mobile and Windows Phone users are out of luck, I think.

Re:XKCD

[spazdor]

I doubt that he takes care of the fact that this is words vs random characters.

Yes, he does.

Just a question: Do you actually understand what is meant by those "bits of entropy" tallies that he's counting using rows of squares? If you don't know about http://en.wikipedia.org/wiki/Shannon_entropy then you're ill equipped to understand what this comic is trying to say.

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.

You can't check a passphrase like that

[arose]

A computer can't tell if a passphrase is random or guessable, even a human wouldn't necceserily be able to. XKCD/diceware style passphrases however are supposed to be easy to remember despite being completely random, so the proper course is to let the computer generate the passphrase.

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.

Survival of the fittest

[Flipstylee]

I use about 9 different passwords ranging from the 6 or 7 characters i'm allowed up to the 20's,
i tier them by importance, so if i ever come into any shit, i know what accounts will need to be checked.

I'll also add that i lock my doors and windows, and own a gun, but because i don't have top notch Ub3r l33t h4xoring
skills or a LOIC, i use the best passwords i'm able.

Re:XKCD

[nzac]

The problem I have with that comic is that the "strong" password is lowercase only.

I doubt Randal intended to make it an example of how to chose a password.
He made it to demonstrate that password policies are poor and alpha numeric passwords with special characters do not guarantee strength (as most people get taught).
Probably most significantly he wanted to say users suck at choosing a good password, they don't have a clue about what they are trying to stop. The number of tech people who think common substitutions make the password exponentially harder to crack too high.

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:Randomly-generated passwords

[dskoll]

16 characters wrong. long, of course. *sigh*

Re:Randomly-generated passwords

[Blue23]

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.

Kudos, you sounds like you're one of those in a minority who do things one right way. (Note: not the only right way.) First, you use different passwords on different accounts, which is a problem the article doesn't (and can't) address. It doesn't matter if it'll take 900 years to break one site A if you use the same password on sites B through Q and site L stores them in cleartext and is compromised. One professional group I'm part of (not IT) used to send me a copy of my username and password in cleartext via snail mail as part of their regular communications. WTF? First, you store it so you can see it, and then you USPS it to me without me expecting it? And have a habit of doing that? Ever heard of identify theft?

I don't think I could manage your way - I'd have too many customized subset password files floating around. One for work that includes some personal things I need to hit to do my job. One at home, which would include some work since I'm on call often. One mobile, since there are a few things I don't care if gets intercepted. But that doesn't mean I shouldn't try - it would cure the issue I have where I don't log into something for a few months and I forget what password I chose for that. I have a rough schema that with a what it's for and some other general knowledge I could get it in a few dozen guesses, but still.

Re:Randomly-generated passwords

[Tom]

You are also totally fucked if you ever lose the file, or find yourself somewhere without access to it.

And you have just defeated the two-factor part of authentication, congratulations. You are storing your passwords in the same place (your computer) where I can easily find your identity as well. You are supposed to store it somewhere else so an attacker who doesn't try brute-forcing, but goes through your stuff can't find both.

Which is why simply writing it down on a post-it note is perfectly ok for the home environment. Ok, maybe not a post-it note, but a piece of paper in your top desk drawer (so visitors don't immediately see it). But almost all attacks on private persons do not involve physical access to your home simply because it isn't worth it. And if someone breaks into your house and takes everything, your Facebook password is probably the least of your worries, and easily changed.
Which, of course, means the one thing you should store somewhere else is the decryption and/or login password for your computer, so the thief don't get it. They'll probably wipe the disk and sell your computer anyways, but if they find the password next to it, they just might look at the sex pictures of you and your spouse just for the fun of it.

Basically: The dirty secret of security is that there are no panaceas. You need to know what the threat scenario is to find a good solution. In your home, where physical access is limited to people you trust anyways, and easy to control, writing passwords down on a piece of paper is preferable to having them stored digitally, because physical access to your home is more effort than digital access to your machine (for most users, maybe not for security-conscious geeks.).
In an office environment, where even if you can lock your office, at least two dozen people have the keys, you might want to keep that paper on your person (your wallet) or use something else.

Yes, I do believe the blind hatred on writing passwords down is another of those irrational, counter-productive ideologies of security that doesn't survive a critical analysis. Because too many security freaks aim for theoretical perfection as the comparison case and not the other alternatives.

Re:Randomly-generated passwords

[rjstanford]

And how do you log into your bank's website from - say - your mobile phone? Or while on holiday? Do you securely tunnel into your computer to retrieve it, then dump it into the clipboard and paste it into the app? Assuming that pasting works, which it may well not for a password field. That's not exactly a sustainable approach for the masses.

Far easier to allow the long passphrase in the first place.

Re:It isn't that passwords are a dead end.

[Anonymous Coward]

Hardware token (aka smartcard)?

Here's how it should work: server sends salt to you, your smart card takes salt, plus your password and signs it with a cryptographic private key that is only accessible with the correct password, sends the signed salt back to the server. Server uses your cryptographic public key to see if it gets the same salt back. Password never leaves your computer (barring keystroke logger, root kit, etc in which case you're already screwed), key never leaves your card, result is cryptographically secure.

Why this isn't done: vendor lock-in, shitty OS support, peripheral card readers, shitty key management infrastructure, shitty key management infrastructure, shitty key management infrastructure, and user doesn't want to have to pay for a smartcard, but they cost money.

The DoD tried this. They've been stymied mostly by relying on contractors who insist on using their bad implementation, and VIPs who insist on bad business practices (why can't my secretary log in as me to send me my e-mail while I'm on the road?). That and the fact that they insist on using MS for everything damn thing.

Re:XKCD

[Rob the Bold]

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.

In WWII, the Germans wanted their cipher system to be as uncrackable as possible. Therefore, they forbid using the same key two days in a row (among other things). Therefore, the British codebreakers knew at least one thing about the code: the key was different than yesterday. They had other rules, too. And every rule reduced the amount of brute-forcing the British had to do. Of course, learning the Germans' key strategy required the deaths of many Bothans. The password requirements of most websites, on the other hand, are broadcast to anyone who cares.

Re:XKCD

[JoeMerchant]

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.

Anything that lasts beyond 100 years cracking time on $100K worth of hardware (actual, including Moore's law growth in analysis power) is fine by me. 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.

Re:XKCD

[vux984]

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

To be fair that is not the xkcd scheme. 4 random words is the xkcd scheme. 4 words that are part of a common pre-existing phrase is not.

Your critisism with the xkcd scheme is sort of like criticising by observing that users are lazy, and rather than pick 4 random words... they'll just pick two. Again... not that's not the xkcd scheme.

But the real problem that needs solving is password reuse. I can remember something like correcthorsebatterystaple, easily enough, but I can't remember a different random set of words for all the literally dozens of logins I have.

And since I feel like ranting I am frustrated in that half the time I'm constrained by annoying limits... must be a least 5 letters but less than 10 must have a punctuation and 1 digit and a capital that isn't the first letter... oh, and i have to change it every 30 days... but i start getting nagged to change it 14 days before it expires... so either i change it every 14 days or I get nagged half of every month that my password is expiring soon. Oh, and I can change it to the last password I used either...

Is it any wonder that people come up really lousy passwords?

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!

Re:Security questions & other sucky policies

[Mal-2]

Also... which pet? And when? Pets get old and die, and I've had some online accounts longer than the lifespan of your average cat, dog, or parakeet.

Re:Security questions & other sucky policies

[BenoitRen]

It makes me nervous when I'm registering for an account they require you to pick a secret question and a secret answer. What I end up doing is pounding on my keyboard so the answer is some gibberish before submitting.

Re:Security questions & other sucky policies

[Blue23]

Q: "What is your pet's name?"

A: "What are stupid questions I don't want to answer truthfully, Alex?"

Yeah, security questions were nifty the first time. Now I feel like they all ask the same questions so if I honestly answered I'd be decreasing my security on every existing site whenever I signed up for a new site.

Now I have a schema for answers that vary non-intuitively by site, but don't match the questions. (Or at least aren't the answers to the questions.)

Re:XKCD

[Rob the Bold]

It makes it weaker by a half. Which is definitely a lot. That roughly halves the time that it would take to crack and doubles the likelihood of randomly guessing the password. The only thing going for it is that you don't know that it's only lower case letters.

Weaker by half? So one less bit, right?

Re:XKCD

[JoeMerchant]

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.

All it takes is a simple twist to "haveityourwaydave" "darksideofthegoon" "thesearenotthefloydsyourelookingfor" and the phrase-dictionary attack falls apart, just like a dictionary attack on regular words.

If the password is being stored hashed (and anybody really cares how "strong" it is) it should be checked against a decent sized rainbow table for common words and phrases before being accepted.

PAM

[Phibz]

I'd love to see a PAM (Pluggable Authentication Module) for this.

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:Hide in plain sight

[spazdor]

Password strength can only be measured relative to the information already available to the hypothetical attacker. If there's a stickynote on your desk with that exact string on it, then assuming the attacker can read it, the long password is about as strong as the short one. The whole text of the note, and then all obvious abbreviations and permutations of it, should be searched long before you've exhausted the space of 10-char strings.

Anyone hoping that the attacker will not incorporate that information into his search just because it happens to read like a plausible-sounding office reminder,is relying on a form of security through obscurity.

Clever scheme to steal your password.

[Anonymous Coward]

Who is passfault! We don't know. Did anyone else start typing in their best passwords to test them then think... wait... I'm just giving these away. They have my IP and my best passwords now.

So I then went to the github site and downloaded the java jar version of this but it is not the same! On the website I tested "abc123" and it said it was weak, less than 1 day, obviously. But the java jar program doesn't notice the pattern and says it would take 8 days to crack.

Time to change my passwords I guess.

Just because you are paranoid doesn't mean they aren't out to get you.

WTF With The Windows Metric...

[BaldingByMicrosoft]

Their demo estimated 18 years to crack a particular password based on a UNIX crypt. Changed the "Password Protection System" to "Microsoft Windows System" and it dropped to 1 day to crack the same password.

Credibility: gone.

Re:WTF With The Windows Metric...

[rjstanford]

At least in the XP days, I've run "password retrieval" programs that were scarily fast and good at reversing the hashed passwords - even long, complex ones. Apparently there was a known weakness in the way that they were stored.

Login names lack security

[__aaltlg1547]

Login names should also not be easily determinable from knowing your identity.

the sign in for your email account should not be your email address. It should be unrelated.

The signin for my slashdot account should not be Shavano.

I should not use my name for either, but my employer requires me to use my name for my email account AND my username on its systems.

Re:Login names lack security

[twistedcubic]

No. Login names can be anything, as long as they don't reveal hard-to-get information, like SSNs. Email addresses are the perfect login--easy to remember and unique worldwide. A strong, secret password, independent of the login, is good enough.

Re:Login names lack security

[__aaltlg1547]

No. Login names can be anything, as long as they don't reveal hard-to-get information, like SSNs. Email addresses are the perfect login--easy to remember and unique worldwide. A strong, secret password, independent of the login, is good enough.

If my login name is Shavano and my name is Steve Havano (which it isn't), and a cracker knows that I work at ... XYZ Corporation, then he knows that to access my account, he needs to log in to the xyz.com server as shavano.

So all he needs is to crack my password, and he can start using things he knows about Steve Havano to crack it. The fact that Steve Havano works at xyz corporation is apparent to anybody who receives an email from shavano@xyz.com

Instead, my hypothetical employer assigns me a username of F2UZG85J. It will be that as long as I work there, so I can remember it even thogh it's moderately difficult to guess. My email says shavano@xyz.com. There's no way to relate them except to ask me or an IT administrator. There's no way for them to even know that such a login name even exists unless somebody tells them and there is no reason for anyone to tell them.

The typical situation is this:
1. Username based on real name and known to everybody.
2. Biographical information about user readily available from sources like Linked In, Facebook, Google, etc.
3. Password that is either hard to guess and hard to remember or easy to guess and easy to remember.

My proposal:
1. Login name that is hard to guess.
2. No way to relate biographical information about the user to the login name.
3. Password that is either hard to guess and hard to remember or easy to remember but hard to guess because you can't leverage biographical information.

Using the email address or anything related to an email address is acceptable ONLY on sites not containing information that could harm you if it were to become known to a criminal. OK for Slashdot or Facebook, not OK for government, banking or on-line sales.

Re:Login names lack security

[Cro Magnon]

As usual, it's a tradeoff between usability and security. An email based login is much easier to remember, especially for accounts that I access once every 5 months, like those accounts I create to buy crap online. Surprisingly, my bank, though not the best on security, does give me a userid that isn't my email or based on my realname.

Re:XKCD

[spazdor]

Even worse, some websites truncate the password silently and just hash the first n characters. Which is horrible.

Easiest solution

[pwnyxpress]

We are so worried about our accounts being hacked and at the same time not remembering our passwords. Put a sticky note under your desk or in some easily retrievable (but not moronically easy to find) location. The likely-hood that someone breaks into your computer and steals stuff is much higher than someone breaking into your house and stealing your passwords and computer (given the amount of respective time required for each). Also, if someone breaks into your house, they probably aren't looking for your Facebook password... Or I could be wrong and just blowing smoke outta my ass.

First Character Of Every 1 Word Works 4 Me

[scottbomb]

Here's an example of something easy to remember and hard to crack:

Take any sentence with 8+ words that includes one or two numbers. Just use the first character. Thrown in a CAP or two.

Example:

My 9 inch Cock is bigger than your puny pecker.

M9iCibtypp

Re:First Character Of Every 1 Word Works 4 Me

[rjstanford]

Better yet, just use the original - vastly harder to crack, since "Mom's 9 indigo corsets inspire bitter thoughts yet purple pleases" also reduces to your abbreviation, yet would hash quite differently itself.

Re:XKCD

[spazdor]

the key was different than yesterday

And, all other things being equal, this rule would be broken once out of every 26^3 days (or whatever Enigma's keyspace was). Going from that probability to guaranteeing that it won't adds virtually no information at all.

Nonetheless, I bet yesterday's key was always one of the first keys they employed in the brute force attack, because they knew that catching some scatterbrained radio operator forgetting to reset his cipher was far more likely than naturally producing the same key two days in a row in an uncompromised random system.

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.

Password generator

[Anonymous Coward]

I've become so annoyed with remembering passwords while trying to keep them complex enough i decided to write a vb application which hashes the web address (or game name) with a single master password salt and returns the first 14 a-z A-Z 0-9 characters (for the sake of universal compatibility). The result being if i used "password" as my master password i'd use "t82CUwcZf26uPL" as the password for slashdot. Obviously i use a much more complex password for any site that i have given my personal details to, but for your run of the mill site it's a perfectly strong password.
It means i can never forget or lose my password, and as long as i can run a simple vb.net application i can always log in.

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:XKCD

[ShanghaiBill]

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

Why would anyone ever want to put unencrypted passwords into a database?

Ubuntu/sudo

[Compaqt]

Very good analysis.

Let me take a different direction:

Like or hate it, Ubuntu is the top OS distribution.

And it asks you for your password. A lot. For updating software. Running gparted. Adminning.

It can get annoying constantly typing it in. Any comments by other Ubuntu users?

Re:Ubuntu/sudo

[robsku]

Feel free to run 100% as root - or you could edit /etc/sudoers so that sudo won't ask password for nothing, which would still be safer than running as root, but IMHO stupid enough that you might just as well enable root login and make it your user account.

Anyway, for serious if you want it to ask less you should learn to configure sudo - you might want to alter the time it takes for sudo "session" to expire if you haven't used it again, or you might configure set of commands you want to be able to run with sudo without asking root password - leaving anything else to still require entering password. If that still feels too annoying - well, IMHO the system should NOT default to be like Windows, and you can still make it act like one if you want anyway (Linux allows you to be stupid if you want - you should have nothing to complain as there is a way to not only take it to both extreme ends but also anywhere between them).

Re:XKCD

[Nemyst]

You can blame lazy programmers, really. Most web-facing programming languages like PHP or databases like MySQL provide easy to use sanitizing methods that make SQL injection null and void.

The problem stems from the fact that, long ago, such methods were unavailable and nobody bothered changing the code to use them since then.

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.

How about not leaking hashed passwords ...

[Lazy Jones]

Why do both XKCD and TFA assume having access to the hashed password? The normal "guessing" case is a password prompt and that'd better not allow 1000 guesses/second (try 10/day or so). The remedy for a compromised database of hashed passwords is: do not use the same credentials in several places. Afraid of someone stealing your hashed password by sniffing it? Use transport level encryption. Apart from that, using a password that you can type quickly and do not need to write down is a good idea.

Re:How about not leaking hashed passwords ...

[allo]

because you always need to look at the worst case, because it WILL happen someday.

Re:How about not leaking hashed passwords ...

[Lazy Jones]

The worst case is someone holding a gun to your head and asking you to log in, IMO...

Re:How about not leaking hashed passwords ...

[dbitter1]

No, duh, that's a different XKCD Cartoon... http://xkcd.com/538/

Re:How about not leaking hashed passwords ...

[allo]

but now, he's standing before the admin, not before you. Now your hashed password is still as strong as the hash.

Re:How about not leaking hashed passwords ...

[Lazy Jones]

No, it's not. The admin will - at gunpoint - log out my existing sessions and ignore my login cookie/session cookies the next time I try to log in and then intercept my plaintext password as I enter it and submit the login form. And of course he will already have given the bad guys access to all my data that is protected with the password. In this worst case / nearly worst case scenario, the strength of the hash is largely irrelevant when the data is stored in unencrypted form or when I have to enter plaintext passwords to log in (both the most common case).

Re:How about not leaking hashed passwords ...

[allo]

no, he will not. because no attacker has the time to wait with the gun at the head of the admin for you to log in.

Re:How about not leaking hashed passwords ...

[spidr_mnky]

Well, let's try it the other way. "Assume your institution will never leak your hash, and rate limits at exactly the thresholds you find appropriate."

"OK. I'm going to keep using mittens22 as my password and sleep like a baby." It doesn't make for much of a discussion.

You're probably right that password handling is more important than password choice, but just as sysadmins ultimately can't make their users choose good passwords, users can't make their sysadmins handle them correctly. "Vote with your feet" counts for something, but not when it's your workplace, and you don't always know how badly your passwords are being mismanaged behind the scenes. So you do what you can.

The remedy for a compromised database of hashed passwords is: do not use the same credentials in several places.

Well, that takes care of part of the problem. However, in that scenario, a good password could (if your institution at least does good hashing) mean more time between database compromise and the compromise of your account - time in which you could change your password.

Two-factor authentication?

[Loopy]

It's interesting to me that we don't employ something like a keyfob that generates a code or a code texted to your cell phone, then combine that with a reasonable password. That way, it doesn't matter if your password gets guessed or compromised: the guesser/compromiser still needs the code from your text/keyfob.

I realize it isn't infallible but it would seem to be a very easy next step that would add a significant barrier to the vast majority of criminal methods in use today.

Re:XKCD

[vux984]

but thanks for spelling out exactly what I just said.

What you said exactly was "my problem with the xkcd scheme..." when your problem is with the users, not the xkcd scheme at all. I realize that's where you ended up, but it was as clear as mud.

The solution to the issue of users picking words, is to just assign them passwords... have dictionary generate the passwords for them.

your password is: fishpopsiclemustardocelot

let them keep hitting "generate" until they see one they like...

Self reply:

[spazdor]

Sorry, Golddess. I didn't read usernames so closely - obviously that wasn't your method.

Re:Self reply:

[Golddess]

No problem, was just curious what you were saying, and I think I understand it now, thanks.

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:Major bugs

[ak3ldama]

I personally use sentences. They are fairly easy to remember and can have a lot of "complexity" to them. Such as a password like this:

The pigs all flew south.
The 9 pigs flew south.
Skinny Seth sat sewing!
The sullen evergreen sat askew.

Passwords like that are easy to remember for accounts used often such as your primary computer account. Different punctuation, vocabulary, capitalization, occasional number usage. It is all there. Not quite the XKCD method, but its been the password generation system that I like. None of the crazy enforced Pa$sW0rd crap that silly people in IT magically think works better. Great article but this isn't hard to realize on your own. A look at how easily a multi-video card system can crack passwords and you obviously have to try something different. I chose sentences.

Re:Major bugs

[Georules]

That's great, but has nothing to do with what I am pointing out. Adding "000" to the front of a string already classified as taking centuries to crack, all of the sudden takes less than 1 day to crack. Can you explain to me why this is?

Re:Major bugs

[ak3ldama]

I can't explain why their cute little algorithm sucks. I was merely agreeing with the basics of the article while saying that I personally prefer sentences, of varying and suspect grammar. Though, a portion of the discussion is predicated on the size of a typical persons vocabulary. I would also propose that someone whose vocabulary is diminutive would be an account that would be less worth breaking into, so the whole thing is silly to a certain extent.

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:Passwords DO suck

[NJRoadfan]

Wouldn't DigiNotar be a good example of that so called "trust"?

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:XKCD

[tqk]

In WWII, the Germans wanted their cipher system to be as uncrackable as possible.

They blew it, from day one:

- they were using Ultra in the Spanish civil war.

- the Poles cracked it and handed the results to the British and French five weeks prior to the outbreak of WWII.

- some Brit geek ran across it, was intrigued by it, and built his own; within a month he was producing Ultra crypto on his own.

- we were lied to about this for "secrecy".

See Vasili Mitrokhin's (chief KGB archivist who, with the help of the British, defected bringing all of his notes) Archive.

I'm still trying to figure out what Turing and Bletchly Park were doing beyond merely extending this stuff.

Re:Hear hear

[twistedcubic]

Dude, everybody does that. It's not the user's fault. It's the designer's fault for creating the stupid requirement.

Re:testing the password

[Swave An deBwoner]

It would be funny if it turned out that Wolfram Alpha was collecting all of the passwords people are typing and using them to populate the tables of their own password cracker. Nah.

Re:XKCD

[tqk]

Oh, ":(){ :|:& };:" you.

PS. Don't do that.

Re:XKCD

[colinrichardday]

Somebody recently (a couple of years ago) demonstrated a build it yourself Beowulf that'd do

Restrict the system to one login attempt per user per second. intruders only get 3x10^7 attempts per year, regardless of their equipment.

screw identity

[johnwerneken]

video world+dog 24x7x365, allow suit for MONETARY damages to give Judge authority to unseal; otherwise let it happen as it happens. Why do you care who I am- you think that would deter ME? Think again. And I don't care who you are nor what you do to my "reputation" since I care not what the entire human race feels thinks says or does - what can you all do? kill me? Torture me? Been done, so wucking fut. I am better able to fight anything imaginable, than anyone else in my opinion able to protect me. I HATE security and privacy and I am convinced that both were invented as an excuse for not serving customers

Re:XKCD

[nzac]

For having to remember something additional about your password you want more than a bit of entropy. Its not too much harder to remember another common word at the end and get eleven or 2048 times the guesses.
Or a proper random substitution, eg replace the 14th letter with ; or insert it afterwards this also gets some real entropy.
If you think your password is possible to crack in a reasonable time and care about what it protects, you are doing it wrong.

Re:XKCD

[colinrichardday]

Weaker by half for each letter. With a 28-letter passphrase, that's a factor of 268 million.

Re:XKCD

[colinrichardday]

72^17=3x10^31. Assuming 100,000 common words, 100,000^4=1x10^20. Using mixed case would require about 35 letters in the passphrase to get equivalent difficulty (2^35=3x!0^11).

Why so hard?

[ryzvonusef]

Even correcthorsebatterystaple is too complex, we can make it *even* simpler.

Most, if not all of us, have some favourite fictional (or not so fictional) media item, why not try a phrase from that?

Harry Potter fan? Try

Wingardium Leviosa!

Time To Crack:
554042313 centuries
Total Passwords in Pattern:
2 Septillion

Naruto fan? Try

Kuchiyose no Jutsu!

Time To Crack:
1623474350 centuries
Total Passwords in Pattern:
5 Septillion

My favourite one is, when I tried

My Little Pony: Friendship is Magic!

Time To Crack:
1.126570510614998e+23 centuries
Total Passwords in Pattern:
341,000 Decillion

*snigger*

And I dare any Brony to *not* know exactly how the phrase above is spelt, (colon and small letter i for is and all)! (but if you forget, you can always look it up on the internet, the format is always the same)

And many other zillion of phrases, like "The Spice Must Flow!" of "Beam me up, Scotty!", just choose one, typing it is easy since you are use to typing it *anyway* when you use it as a meme or catchphrase on your favourite fandom forums, and in case of doubt, you can always look it up on your fandom wikia.

Of course, if your site (e.g. banks) forces a *Maximum* limit, then you are screwed :(

Re:Why so hard?

[neonsignal]

You seem rather trusting of the figures that come out of this bit of software.

"p a s s w o r d 1"
gives a result of 427445 centuries

Re:Why so hard?

[ryzvonusef]

It's true that I am rather trusting of that software, since I can only barely grasp the science behind it (I may be a nerd/geek/whatever, but education wise, I am merely an student-accountant after all, not a computer scientist)

But what I understand is that all those spaces between each letter in your example amount to a much greater weakness in the ability of the $900 software to crack.

Also, my point was that, if we *are* recommending longer, memorable phrases as a guideline for better passwords, then there exists options that are not only more stronger, but even more easier to remember than the format recommended by xkcd.

In other words, people can easily make (and remember!) strong passwords from there every day phrases, and are not merely limited to the "random four word" example from xkcd. The problem with "correct horse battery staple: is that you might forget the word order, but you would not, with, say, "Wingardium Leviosa!"

Re:Why so hard?

[neonsignal]

There isn't a lot of science behind it; it is an exercise in simple probability. Once you define the set of likely passwords, then the time to crack it is directly proportional to the size of that set. So if for example the password is a random 4 character lowercase password, then there are 26 times 26 times 26 times 26 ways to build it. You might want to include 1, 2, and 3 character passwords in that total, but whatever, that gives you a rough idea of how hard it is.

The software covers about a dozen password strategies, calculating the set of passwords that use that strategy (for a particular length password). But it does not cover all the strategies that people might come up with, and forcing people use the software would mean that they will come up with relatively easy-to-guess ways around it. Hence my spaced-out password looks hard to the software, but it might not be too hard for a real person to guess my strategy, and once they have, I am cactus.

It is hard to quantify how likely a particular strategy is, but we know from experience that humans aren't that creative; simply choosing a different strategy does not make the password much stronger. What matters most is the size of the set of passwords that would result from that strategy.

Unfortunately there aren't as many culturally significant phrases as you might think. For example, wikiquote, which is quite comprehensive, has only about 20000 pages, each with say around a hundred quotes. This amounts to a set of only two million possibilities (which include most of the ones you suggested). We can quibble about the exact number, but I think I am being generous because some of these are much more popular than others and would be tested first. In comparison, a mere two words chosen randomly from a dictionary of common words will have a similar number of combinations (and none are more likely than any other, because they are chosen at random).

I understand your point that memorability is an issue. But it is the combination of random choices that best achieves password strength. The point of choosing words instead of characters is not that they are more memorable (four words is roughly as hard to remember as four characters), but that the set of words is larger than the set of characters. Although there are quite a few fandom phrases, they aren't going to be chosen at random by the individual, and they have only chosen one.

To be honest, if you cannot remember a strong random password or passphrase, then it is better to write it down rather than make it weaker. At least then you only have to physically secure the piece of paper, and a piece of paper is not subject to network attacks.

Problem-oriented mindset. Gamify!

[real-modo]

Rather than put up with a problem which is mainly caused by a broken way of looking at passwords - as a frowny-face stern-eyebrows thing - why not create a solution?

Here's one: make creating a good password into a game.

Download and print the Diceware wordlist and instructions, and buy five dice. Package the list, instructions and dice in a box - say, a shoe-box. Stick a nice "game-y" cover on the box. Set aside a desk in IT (one immediately in front of a blank wall) as the "password desk". Instruct locked-out users that they have to come to IT and play the password game to get their next password. A user uses the Diceware method to generate a password, types it on a typewriter ten times to memorise it, and then shreds the paper (a bit of security theater that might actually be useful).

(In bigger organisations, make up a password game box for each unit manager or each floor of the building(s). Sourcing enough typewriters and shredders might be a problem, so type-and-shred might have to be write-and-eat - on rice paper, of course.)

If you really have to - BOFH habits are hard to overcome - you can still use a stick: a policy that says "if your account is hacked and you were not using a password from the game, you're sacked. Instantly. And billed for costs. If you were using a password from the game, then you're fine, unless we find you wrote your password or messsaged it to someone else."

Unreliable cracking estimate

[AliasMarlowe]

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

FWIW, it claims it would take a few hundred billion centuries to crack one of my former home passwords (I changed it last year, but remember it well). However, while I think that password/passphrase was probably secure enough, the tool's dictionary appears to be short on words so its estimate of brute-force cracking time is not reliable.
It flagged that disused passphrase as having mis-spelled words largely because it did not recognize two fairly common words stuck together. Actually, the passphrase had no mis-spellings and no 1337-substitutions or interstitial characters. It also flagged the passphrase as having a mis-spelled US city because it did not recognize another fairly common word. BTW, by fairly common words, I don't mean rare or scientific terms like "coprophage" or "syzygy".

Re:Unreliable cracking estimate

[lewko]

Since when is coprophage rare? This is the Internet.

Re:Unreliable cracking estimate

[wisnoskij]

What claims?
And then you go on to explain how bad this utility is at actually estimating this.
The easiest way to estimate the time it would take to crack a password is to measure its length but crackers don't just use brute force and this utility does not know that you use the same dictionary based password with modifications.

Re:XKCD

[CBravo]

How else can you mandate a password policy that requires that no more than 3 characters may be the same...

yes

[Tom]

I gave a speech on this topic recently, and can only support everything said. Most password policies suck so hard, my rough estimates (presented to an academic audience, no refutations so far) show that they lower the complexity of passwords by at least eight orders of magnitude.

That's not a little bit, that is what brings them down into ranges that are brute-forceable.

I think I should translate the paper into english and get it published somewhere.

Re:It isn't that passwords are a dead end.

[CBravo]

One can do the same with public/private key pairs. Just, instead of a password, give them a specific public key. Refresh that at will. The only thing necessary, as one should not want to keep keypairs around, is a good HW implementation which integrates with browsers.

Re:XKCD

[tqk]

Somebody recently (a couple of years ago) demonstrated a build it yourself Beowulf that'd do

Restrict the system to one login attempt per user per second. intruders only get 3x10^7 attempts per year, regardless of their equipment.

You're assuming they're using networking logins. I'm assuming they've got your in your box and have got /etc/shadow and can go at it at their leisure. Ha, haaaaa!

Sorry. :-) Assume the worst. Hope for the best.

And that is if you limit yourself to 1 language

[aepervius]

Pferde papillon neko-inu-mushi gato dog.

Sure in that speicific case I only used animals name, but that' incidental, that is 5 languages in that password and it is frigging easy to remember, and you rose your space to work with from 20000 headword to many many many more.

Re:XKCD

[DriedClexler]

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.

I go one step further and have all the hashing done client-side!

Re:XKCD

[pjt33]

I'm still trying to figure out what Turing and Bletchly Park were doing beyond merely extending this stuff.

Automating it and applying it to a practical purpose. Breaking the ciphers wasn't the end in itself: getting access to the plaintext as fast as possible in order to inform military operations while the intelligence was still relevant was the end.

Usernames part of the problem...

[Eth1csGrad1ent]

Usernames for a vast number of sites default to you email address - with a different password for each site.
As such, people end up sticking patterns in their passwords to keep track of which is which... or, worse, they use the same pwd for every account.

I'm more worried about the number of times I've put the wrong username / password combo in a login prompt for some site, when that username/password is valid for another side.

muscle memory too, is a killer in this regard.

eg if your email address is the same as your domain username - how many sites have you given your work account details to due to muscle memory alone?
Sure, the site failed the login - but who says they destroyed the details of the attempt ?

Re:XKCD

[shvytejimas]

By applying the character check BEFORE hashing the password and storing the hash in the database?

Re:testing the password

[allo]

you forgot the spaces

Re:XKCD

[BlueParrot]

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

which maps to:
purchasing persecute platitudes escalations consummation mum intoned

Your pass-phrase is quite tricky to remember and type reliably. A better approach is to use different languages in order to increase the dictionary size. If you pick at random among the languages that use latin script, you can easily get a dictionary size above a million words. Just 4 such words would give a number of combinations exceeding 10^24. Even if you could try a thousand trillion combinations per second, it would still take in excess of thirty years to try them all.

you already do remember 26 chars "random" password

[postijate]

Actually everyone of us can quite easily remember 26 characters long random "password". The one we _do_ remember starts with "abcdefg..". If that isn't random (the order of alphabets) then maybe someone can tell us an easy way to conclude why alphabet "a" is followed by "b" and then why it's followed by "c". AFAIK the order of alphabets is just an agreement and could be as well "qwertyuio..". My point is that random passwords can be remembered the same way as the order of alphabets. At least here in Finland kids are taught to remember alphabets by "singing" them in order. Random passwords can be quite easily remembered by the same way. Repeat the characters in your mind (speak them to yourself in your mind) ten times (or something). It's also good way to type the password a few times while repeating it in mind. It's also good to use the password for a few times during the day or a next few. If you can remember the layout of your keyboard then why much shorter random password should be any harder? I do agree that sentences are easier to remember and the xkcd comic has it's point.

Mine takes a while...

[sproketboy]

83978 centuries HAHAHAH

Re:XKCD

[Rob the Bold]

the key was different than yesterday

And, all other things being equal, this rule would be broken once out of every 26^3 days (or whatever Enigma's keyspace was). Going from that probability to guaranteeing that it won't adds virtually no information at all.

You'd think I'd eventually learn not to use examples on Slashdot . . .

Special Symbols

[wisnoskij]

I cannot stress how important special symbols are if you don't want a password cracker to work.
If you pop default OPH XP Cracking disk in a drive the only thing (bar a locked bios and no boot from disk) that is going to stop you is a special character. In many real life situations "#" is a safer password then "ajrfvd".

Need a new approach altogether

[jbwolfe]

I posted early in this thread before I had a chance to see everyone else thoughts. Now I see everyone talking about brute force attacks with GPUs and salted hash tables and 10^24, dictionary words only vs special characters etc. Do passwords get cracked with brute force in practice? Does any website/intranet expect to be attacked this way (not that anyone would admit to being a victim of this)? If you believe that you will be a potential victim of a brute force attack, then you believe someone will have uninterrupted access to your "secure" resource and you haven't really secured anything. Seems to me your solving the wrong problem. Extremely secure passwords are not a panacea to computer security. In fact passwords need only be mildly secure and just one aspect of the overall approach to securing your resource.

My early post suggested expanding the idea of "passwords" to include dynamic info that only the user would know rather than just a passphrase- some sites are already doing this. The replies suggested that sharing this info with the secured site means that it would no longer be only me who knew it. But that's already true then, isn't it? My point is the problem needs to be looked at differently- instead of letting computers do security like a computer, we should make them do it like humans. How do humans secure real (vice virtual) assets? What are we good at and where are our failures? It should actually be easier to achieve the sought after increase in security than what we are currently doing. The only brute force cracks are distributed test projects and complex passwords are more often less secure. If you cannot remember your password, you're gonna have to record it somewhere.

Passwords are dead!

[Rambo Tribble]

Long live the passweird!

Re:XKCD

[JoeMerchant]

And, I wasn't really being sarcastic - I am truly glad that people work on these problems.

On the other hand, my favorite stream ciphers are based on very long period PRNGs like the Mersenne Twister - period of 2^19937, make your key as strong as you like.

Re:XKCD

[colinrichardday]

If they have that kind of access, why worry about passwords?

Re:XKCD

[JoeMerchant]

Somebody recently (a couple of years ago) demonstrated a build it yourself Beowulf that'd do

Restrict the system to one login attempt per user per second. intruders only get 3x10^7 attempts per year, regardless of their equipment.

You're assuming they're using networking logins. I'm assuming they've got your in your box and have got /etc/shadow and can go at it at their leisure. Ha, haaaaa!

Sorry. :-) Assume the worst. Hope for the best.

Yeah, my favorite analogy is that you're encasing your secret in a strong box, but the people trying to break in have unlimited unfettered access to it. So, even if it's one meter thick titanium/diamond composite alloy, it might be expensive and slow to get in, but if they throw the resources at it, they'll get in eventually.

Of course, current crypto theory allows for exponential growth of cracking difficulty with linear growth in password length, so, under current theories, you can easily make it impractically expensive to ever break in - if your users can remember a sufficiently complex password for the front door.

Re:XKCD

[tqk]

Yeah, my favorite analogy is that you're encasing your secret in a strong box, but the people trying to break in have unlimited unfettered access to it.

I like the way you think. Yes, assume attackers have all the time in the world (ie., they've got your /etc/shadow). What's *our* downside? Really?

To the others in thread, yeah, they're in. That doesn't necessarily mean "they're in". If everything's crypto'd, they're still fscked (assuming no keyloggers).

BTW, I'm no crypto/security expert, so don't expect miracles from me. Just sayin'.

Re:Passfault is faulty, socially irresponsible

[Tacvek]

Did you set the options correctly?
If I set the cracking hardware to be "an average GPU" and the same password that would take 2 days when protected by Microsoft Windows System (1 round md4) would take 54 centuries using bcrypt.

Admittedly the software on the website is only set up as a demonstration. It grossly underestimates the speed of GPU based cracking at the moment (it multiplies the speed of CPU by the number of stream processors), and lacks many types like crypt-md5.

But the underlying concept (determine the pattern used, assume the cracker knows the pattern used, calculate the number of passwords that fit this pattern, divide by crackers check rate) is sound.

Re:XKCD

[sco08y]

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

And why in God's name can't sites do this? Especially if you want to make four-word passwords the norm, just generate them.

Re:XKCD

[spazdor]

For having to remember something additional about your password you want more than a bit of entropy.

Ok, but even if it does add only a bit, that still meets the definition of "exponential". /pedant

Re:XKCD

[CBravo]

I guess I should finish my sentences...

...may be the same of previous passwords.

Less Paul complexity passwords

[denn1s]

I recommend less paul passwords, you know, the google doodle guitar thing. just pick a song you like, and learn how to play it in the keyboard. If you are good enough you could even throw shift as if it was a sustained pedal. Its very easy to memorize (if you pick a good song), entropy should be enough to make dictionary attacks void and the length will throw brute force attacks off. Just be sure to pick a fast paced song since you will most likely type with the songs tempo.

You're all doing it wrong

[blubadger]

The solution to the password non-problem is obvious. I worked it out it years ago and never looked back.

1. Think of a hash which turns two letters into 6-letters-plus-2-numbers (use alphabet position for the numbers)
2. Use it to encode the first two letters of the site or app name

That's it. You get a different non-alphabet password for every site or app, and you'll never forget anything if you remember the hash. Why the hell are we having this debate? We should just get on with it and evangelize for this technique. It's easy and failproof. The only hard bit is learning the number-correspondence of letters, but even just using a favorite number instead the solution is somewhat secure.

Re:XKCD

[chrismcb]

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.

Why is there a problem with them if they are returned in a variable (how else do you plan on returning them, smoke signals?)
When one person writes one piece, and another writes another piece, you have things like specifications to help you with the communication issue. It works in other areas of programming, why can't it work with verifying passwords? Better yet, instead of saying "Hmm I'll just strip these characters because I am a moron" why not write the code to handle ALL the characters. You know it is usually easier and simpler to do that anyways.
That is what kills me. It is actually easier to do the right thing, that it is to prevent you from not using certain characters because you don't like those characters.

Re:XKCD

[Tom]

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.

Who said the users get to pick the words?

It's trivial to have all or some of the words picked at random.

Quiet protoplasm?

[danaris]

Do you also like lively protoplasm?

Dan Aris

Re:XKCD

[nzac]

No its not exponential, you just are doubling it. Only if you chose to represent it as 2^x does it look exponential.(2*2^x=2^x+1)
The inverse exponential is what you should be using to calculate your linear multiplier in bits.

Take away 'what you know' and your pass is secure.

[briester]

So we have passwords because we need to meet the security criteria 'what you know,' because its impossible for the server to know 'what you are' or 'what you have.'

Well, that doesn't mean you can't rely on biometrics or physical keys as passwords... It just means the server doesn't KNOW you're using one of those methods.

The easiest is to visit password card and print off a password card. This is your new PHYSICAL INTERNET KEY!

It generates a string of completely random letters, numbers, and symbols. These are in a grid, so you don't have to remember your whole password - just where your password begins. This defeats the number one security flaw: laziness. Eventually everyone gets lazy. So getting in the habit of *secure laziness,* like using a password card, prevents stupid passwords like 110v3k1tt3ns.

The importance of the password card is in the dictionary. Yeah, yeah, its hard to guess a 4-8 word sentence of random words. But its easy to compile a list of known passwords and use them for all future brute-forces. Every successful brute-force makes *every single subsequent attack* easier. The only way to combat that fact is with truly random passwords using every possible character-set, and never ever using the same password for more than one thing.

Using a password card allows you to have one single 'key' to get into every secure location, without ever re-using a password. Its easy for you, difficult for hackers.

Re:XKCD

[spazdor]

common substitutions make the password exponentially harder to crack

each one doubles the effective keyspace.

Successive doubling is an example of

wait for it

exponential growth

Re:XKCD

[arose]

The government has, the Estonian government that is. Now for the hard part, getting everyone else to adopt a sane, user friendly system like that.

*Strings* of words

[DrYak]

Yes, the password is based on dictionary words.
Except there are several of them in a row.

Say that there are 5'000 common words in English.
The phrase has to make sense, so actually there's only a subset of those 5000 which can follow a given word without breaking grammar rules.
Let's say this subset of "next grammatically correct option" is 1000.

A string of five word gives you a space of:
1000 ^ 5 = 10 ^ 15 possibilities

When using a combination of 80 sings (small and capital letters, numbers and a couple of punctuation marks), this is exactly the same as :
ln(10^5)/ln(80) = 8.4

Thus picking such a phrase would give roughly the same password strength as using 8 purely random characters (enough for the usual requirement for most passwords).

If "at least 8 characters long, including capital letters, numbers and punctuation" passwords are good for most situation, this phrase should do the trick, even more so because most passwords people will provide won't actually be purely random strings but modified words ("(hick3n!", "sHit_666", etc.) which are much more easy to crack than purely random strings.

Now of course, a completely alternate strategy would be to generate 64-caracters long strings of purely random shit, and then use a keyring manager to remember them for you.
(If the authentication supports non-ASCII caracters, that would give you roughly 10^149 combinations. Down to 10^126 if you use only 96 printable symbols)

Or even move to public/private key strategy for authentication.