Beyond brute force.
May 28, 2013 9:41 AM   Subscribe

Anatomy of a hack: How crackers ransack passwords like “qeadzcwrsfxv1331” Hackers get %90 of an MD5 password database using multiple analysis techniques including Markov chains, mask, combinator and hybrid attacks. These attacks combine dictionaries of previously-recovered passwords and passphrases with brute force and statistical analysis to expand the power of password cracking.
posted by CBrachyrhynchos (153 comments total) 52 users marked this as a favorite

 
The long and short of it: Your password sucks, and there's nothing you can do about it.
posted by pjern at 9:49 AM on May 28, 2013 [2 favorites]


Remember back in the day when /etc/passwd was world-readable? That turned out to have been a really bad idea.
posted by Slothrup at 9:53 AM on May 28, 2013 [3 favorites]


Uh, that's definitely not the long and short of it. Use 11-character passwords mixed with numbers and characters, and don't reuse the same passwords on other sites.

The dynamic has totally changed between passwords and crackers- it used to be that you'd have to be most worried about someone looking over your shoulder or you writing down your password. But now it's definitely more likely that some computer program will find your encrypted password on some stolen database and reverse it. That doesn't mean there's nothing you can do about it.

I'll also add that I agree that this totally sucks, and we need to figure out a better system.
posted by thewumpusisdead at 9:55 AM on May 28, 2013 [6 favorites]


On the one hand: this article is talking about unsalted passwords and MD5 hashing, both of which have been well known to be the wrong thing for quite a while now. That doesn't mean there's not a lot of people out there doing the wrong thing right now, sure, and if you have any choice in the matter you shouldn't ever use a service that arbitrarily restricts the content of a password field.

What I mean by that is, when you try to sign up for something, and it says something like "You can't use @,',!,~,*, [or ] in your password" or "your password cannot be more than 10 characters long" (or whatever) then if you have any choice in the matter you shouldn't use that product. Stuff like that is like the brightly-colored spots on venomous frogs or poisonous caterpillars, it's nature's way of saying "walk away, do not engage".

So when you say "The long and short of it: Your password sucks, and there's nothing you can do about it." that's not entirely true. There's a difference between decrypting a hash you already have, and hit-testing a site for weak passwords. You can have a sufficiently complicated password that it can't be hit-tested online in a reasonable time (one per site, use a password manager) and as much as possible decline to use sites that don't do the right thing on the server side.

On the other hand, funny story - all these machines people are building to mine bitcoins can also be used to chew through password hashes. So when the Bitcoin thing is played out, there's going to be an awful lot of insanely fast, single-purpose password-cracking hardware in the world looking for a raison d'etre, and they're going to find one.

So there's also that. Passwords are going to be around for a long time, but it's not going to be _just_ passwords for very much longer, I think.

The real problem we have to fix, in my opinion, is the whole "my inbox is a skeleton key to everything else in my entire life" problem, and I'm really not sure what to do about that.
posted by mhoye at 9:58 AM on May 28, 2013 [44 favorites]


They need to add an online password safety paragraph to the learned helplessness wiki article.
posted by elizardbits at 9:59 AM on May 28, 2013 [4 favorites]



They need to add an online password safety paragraph to the learned helplessness wiki article


They do. What is best practice for keeping track of 20/30 11 character passwords mixed with numbers and characters? I would never remember them, so, as was written above, the best idea to just write them down and keep a list and home and at work?
posted by josher71 at 10:01 AM on May 28, 2013 [1 favorite]


Well, a 10+-letter, actually randomly generated password would still be secure. Kind of forces you to use a password manager though.

On the other hand, if we're assuming the use of a password manager (as opposed to a login form and a memorized password), then we should just have everyone use asymmetric crypto with strong keys.

I think a difficulty is that the approach the user wants to use depends on their relationship to the site. I can remember two or three actually-secure passwords. A given website can't know ahead of time whether they're going to get one of those, or one of the password-manager-kept passwords.

The real problem we have to fix, in my opinion, is the whole "my inbox is a skeleton key to everything else in my entire life" problem

Very much this.

Remember back in the day when /etc/passwd was world-readable? That turned out to have been a really bad idea.

It was a perfectly good idea 30 or 40 years ago, when it was implemented— especially as the other typical approach was storing them in plaintext— it's just not a good idea any more.
posted by hattifattener at 10:02 AM on May 28, 2013


don't reuse the same passwords on other sites

What about reusing parts of a password? Like let's say I preface every one of my passwords with JkL$ and then append a string of characters of varying length. Does the fact that every one of these passwords starts out with the same four characters compromise its security?
posted by Sternmeyer at 10:05 AM on May 28, 2013


Two-factor authentication with physical tokens needs to become a thing on every site that stores anything of even remote importance. Hell, one factor authentication. Ditch passwords entirely. Moore's law is destroying the system and it needs replacing, because you're never going to get more than a tiny percentage of users to buy in (figure of speech, I know they're free) to a service like KeePass.
posted by Holy Zarquon's Singing Fish at 10:06 AM on May 28, 2013 [2 favorites]


What is best practice for keeping track of 20/30 11 character passwords mixed with numbers and characters?

KeePass or something similar.
posted by one more dead town's last parade at 10:06 AM on May 28, 2013 [5 favorites]


Does the fact that every one of these passwords starts out with the same four characters compromise its security?

A hundred thousand million times yes. If two of those passwords get leaked, JkL$ will end up in the dictionaries of common passwords as a prefix.
posted by Holy Zarquon's Singing Fish at 10:08 AM on May 28, 2013 [3 favorites]


Uh, that's definitely not the long and short of it. Use 11-character passwords mixed with numbers and characters, and don't reuse the same passwords on other sites.

hattifattener is more accurate, but it should be noted that the graphic on the 2nd page of the article only lists 3 options: Desktop - Core i7 980x, GPU - Radeon 6970, and Cloud - Amazon EC2. Then there are monster cracking systems, like the 25-GPU cluster that can "crack every standard Windows password in 6 hours". That pushes the likelihood of brute forcing a password out a character or two.

Every extra character (generally*) makes your password harder to crack. And that's generally* because smart crackers learn from widely used patterns, like XKCD's "string a few words together" idea, and set up joint word dictionary brute force attacks.
posted by filthy light thief at 10:10 AM on May 28, 2013 [2 favorites]


I like LastPass and use it to generate and remember random passwords for everything.
posted by East Manitoba Regional Junior Kabaddi Champion '94 at 10:12 AM on May 28, 2013 [5 favorites]


BUT MY FOUR-DIGIT PIN IS STILL SECURE RIGHT
posted by Sys Rq at 10:12 AM on May 28, 2013 [31 favorites]


The university I work at uses passphrases- 15 characters or more, four words with spaces between them. This strikes me as a good way to do things.
posted by Pope Guilty at 10:13 AM on May 28, 2013 [3 favorites]


Like let's say I preface every one of my passwords with JkL$ and then append a string of characters of varying length. Does the fact that every one of these passwords starts out with the same four characters compromise its security?

Why use it as a prefix instead of evenly distributing those characters throughout the rest?
posted by Jpfed at 10:13 AM on May 28, 2013


I no longer have passwords. I have an authentication agent that lives in my browser and proves my identity to websites like Metafilter. Sadly, the authentication protocol requires sending my secret token rather than doing some rational public key protocol. And the details of figuring out how to transmit the token to each website are needlessly complex.
posted by Nelson at 10:13 AM on May 28, 2013 [4 favorites]


I personally use LastPass, but I don't make any illusions about it being completely secure. It's probably less secure for me since it presents a big, tasty target for crackers, and since their database HAS to be reversible, once someone cracks their DB, all my passwords are toast. So it's essentially like me having a big password booklet, only this time everybody in the world knows where it is (as well as the password booklets for thousands of other people.

The reason I use it anyway is that it's easier to use than a password book, and it's still better than reusing the same password on every site, which I would do if it weren't dead simple to use LastPass.

There's also the argument that LastPass (and the other password keeper companies) have more to lose and only have one thing to do and therefore will do it well. Not sure I buy that one either.
posted by thewumpusisdead at 10:13 AM on May 28, 2013 [2 favorites]


The real problem we have to fix, in my opinion, is the whole "my inbox is a skeleton key to everything else in my entire life" problem, and I'm really not sure what to do about that.

Personally I think security should move from more of a "prevent attacks from succeeding" point of view to a "mitigate damage from successful attacks" point of view. Credit cards are a good example of a system that is designed around the fact that fraud will happen and protecting the customer from any negative impacts of it happening. It's statistically likely that someone will steal your credit card number at some point, but it's also likely that you'll be notified of it by either a phone call or some other contact method that the attacker does not have control of, and it will get reversed. There are many online systems that are absolutely not designed around notifying the customer that their account has been compromised and ensuring that no damage is done from compromised accounts.
posted by burnmp3s at 10:13 AM on May 28, 2013 [7 favorites]


BUT MY FOUR-DIGIT PIN IS STILL SECURE RIGHT

ATMs are a great example of two-factor authentication- your card without your PIN or your PIN without your card are useless at an ATM.
posted by Pope Guilty at 10:14 AM on May 28, 2013 [4 favorites]


My password is ^#Ls@#PO`XXLNpo . Is that safe?
posted by cacofonie at 10:16 AM on May 28, 2013 [10 favorites]


I just use hunter2, on the premise that nobody could possibly be stupid enough to use hunter2, therefore it's safe to use hunter2.
posted by Pope Guilty at 10:21 AM on May 28, 2013 [18 favorites]


That depends, what's your e-mail?
posted by Green With You at 10:21 AM on May 28, 2013 [3 favorites]


I made up a password protocol that builds a pattern of capital/lowercase letters, numbers and punctuation marks off the URL itself. Consequently, each one of my passwords is unique but I don't have to remember any of them: just the rules I use to define them. Am I kidding myself?
posted by carmicha at 10:22 AM on May 28, 2013 [1 favorite]


This is scary to a techno-newb like me. It reinforces my belief that there isn't anything I can do to be secure--or at least anything I can understand and implement to be secure.

Question: what about just having thumbprint readers on every computer/mouse/keyboard and using that for identification? Or is that hackable too?
posted by dios at 10:22 AM on May 28, 2013 [1 favorite]


The university I work at uses passphrases- 15 characters or more, four words with spaces between them. This strikes me as a good way to do things.

Except, crackers know of that XKCD comic, too, and the response to "pass phrases" is a "combinator attack." Also, using common replacement characters (zero for the letter O, one for the letter i or L, $ for the letter s) are also known by crackers.

The problem is, anything with a logical pattern can be programmed into cracking software. And decent crackers, as the article mentions, try to learn from the source of the passwords to custom tailor their attack, reading on the requirements for passwords, and identifying common interests and the language often used.
posted by filthy light thief at 10:24 AM on May 28, 2013 [4 favorites]


They do. What is best practice for keeping track of 20/30 11 character passwords mixed with numbers and characters? I would never remember them, so, as was written above, the best idea to just write them down and keep a list and home and at work?

I use a special SD card (actually two cards) for this purpose. I suppose someone could steal the SD card, but there are varying levels of risk.
posted by KokuRyu at 10:24 AM on May 28, 2013


What I mean by that is, when you try to sign up for something, and it says something like "You can't use @,',!,~,*, [or ] in your password" or "your password cannot be more than 10 characters long" (or whatever) then if you have any choice in the matter you shouldn't use that product. Stuff like that is like the brightly-colored spots on venomous frogs or poisonous caterpillars, it's nature's way of saying "walk away, do not engage".

Another good test: try out the "I forgot my password feature." If it tells you what your password is (there are services that do this), you have proven your password is being stored as plaintext.

all these machines people are building to mine bitcoins can also be used to chew through password hashes. So when the Bitcoin thing is played out, there's going to be an awful lot of insanely fast, single-purpose password-cracking hardware in the world looking for a raison d'etre, and they're going to find one.

I don't think this is true. Those machines are very application specific: they can only do SHA1 hashes (or whatever bitcoin uses, not MD5, scrypt, or bcrypt) and the tradeoffs that would be required to make them fixable enough to crack passwords would make them uncompetitive at mining bitcoins.

That's not to say scary-fast dedicated hardware isn't out there, just that it probably never had anything to do with bitcoin.
posted by cosmic.osmo at 10:24 AM on May 28, 2013 [1 favorite]


Well, dios, I suppose they could hack off your thumb sort of hackable ;)
posted by The Hyacinth Girl at 10:24 AM on May 28, 2013 [3 favorites]


Question: what about just having thumbprint readers on every computer/mouse/keyboard and using that for identification? Or is that hackable too?

Well, your thumb is hack-offable.
posted by jason_steakums at 10:24 AM on May 28, 2013 [4 favorites]


carmicha, I think that honestly is the best practice, and one that I used to use. The only problem is that 1) some sites have restrictions on passwords, which might force you to break your rules, and 2) if a site gets hacked and you have to change your password, can you remember that one exception?
posted by thewumpusisdead at 10:25 AM on May 28, 2013 [1 favorite]


I made up a password protocol that builds a pattern of capital/lowercase letters, numbers and punctuation marks off the URL itself. Consequently, each one of my passwords is unique but I don't have to remember any of them: just the rules I use to define them. Am I kidding myself?

I do something similar to this. I've encountered two problems with this:

1. Sites with limits on their passwords (e.g. lengths or characters allowed) that won't accept my generated password.
2. I once executed my procedure incorrectly, and since I didn't know I had made a mistake, went to change my password to what it should be. When I ran the procedure again to input my "new" password into the box, the site told me I couldn't use a password I had used before! Oops.
posted by Jpfed at 10:26 AM on May 28, 2013 [1 favorite]


Or what thewumpusisdead said.
posted by Jpfed at 10:27 AM on May 28, 2013


Well, dios, I suppose they could hack off your thumb sort of hackable ;)

In the original design document of Doom, all the locks used fingerprint identifications, and one of the important items in the game was the severed hand of somebody higher ranked than the protagonist so that you could open locked doors.
posted by Pope Guilty at 10:27 AM on May 28, 2013 [4 favorites]


I maintain password security by not having any money or other reason for someone to get into any of my accounts.
posted by shakespeherian at 10:28 AM on May 28, 2013 [16 favorites]


I made up a password protocol that builds a pattern of capital/lowercase letters, numbers and punctuation marks off the URL itself. Consequently, each one of my passwords is unique but I don't have to remember any of them: just the rules I use to define them. Am I kidding myself?

Only if there's a logical pattern that can be fairly easily coded for subsequent brute force attacks.


Question: what about just having thumbprint readers on every computer/mouse/keyboard and using that for identification? Or is that hackable too?

Depends on the system. There needs to be some central database of passcode data, so if that data leaked, and there was some way to directly input data for verification, hackers don't even need fingers.

Everything has cracks, on the level of hardware, software, or social. Even one-time pads are insecure when handled by more than one person. "Three can keep a secret if two of them are dead."
posted by filthy light thief at 10:29 AM on May 28, 2013


"my inbox is a skeleton key to everything else in my entire life" problem, and I'm really not sure what to do about that.

Google offers two-factor authentication to Gmail, using your cellphone as the second factor. You should probably enable that for a start.

There are some issues with their 2FA implementation but none so severe that it's not worth using (i.e. none so bad that it hurts your from a security standpoint), at least that I have seen. You still have a password, which should be complex and not reused anywhere else -- and I'd also not keep it in LastPass alongside everything else, because it's so damned important, but instead keep it on paper in a safe place somewhere -- but then in addition you have the second factor that would keep someone from using that password if they were able to sniff it, e.g. using a simple keylogger.
posted by Kadin2048 at 10:32 AM on May 28, 2013


Uh, that's definitely not the long and short of it.

Seriously. I thought a password like

I w@nT to HELP kids 3AT fr##zzleberr4s

was long and complex enough to crack that it was mostly safe?

Just memorize all your passwords like that.
posted by mrgrimm at 10:33 AM on May 28, 2013


One of the main points of the article is that password length and the inclusion of special characters are insufficient criteria for security in light of the fact that they can be undermined by the use of predictable patterns like that.
posted by invitapriore at 10:35 AM on May 28, 2013


So there are no perfect solutions to prevent passwords from being brute forced, only varying degrees of mitigation?
posted by echocollate at 10:35 AM on May 28, 2013 [1 favorite]


Use 11-character passwords mixed with numbers and characters, and don't reuse the same passwords on other sites.

It depends, if the first 8 characters are in a password dictionary, the last three can be brute forced.

If the first six and last five characters are in the password dictionary separately, the combination can be found.

If the frequencies of letters and their ordering in your password are statistically similar to those in an available corpus, then a Markov chain technique pushes the complexity barrier out a bit. (This is actually an assumption that's the foundation of classic cryptoanalysis.)
posted by CBrachyrhynchos at 10:38 AM on May 28, 2013


So there are no perfect solutions to prevent passwords from being brute forced, only varying degrees of mitigation?

No perfect solutions, but as a developer, you can use better hashing functions to prevent being able to churn through 8 billion a second. Hashing functions like bcrypt, scrypt, and PBKDF2, that allow you to specify how much time is spent on a hash, are good.
posted by ceol at 10:41 AM on May 28, 2013


filthy light thief: Even one-time pads are insecure when handled by more than one person.

Or reused, or well-intentioned people didn't trust the RNG and tweaked them to their own intuitions.
posted by CBrachyrhynchos at 10:42 AM on May 28, 2013


Great read. One thing to consider was the tiny amount of computing power these folk needed, and they were doing this on the writers deadline it seemed. They made many concessions that they might not have made with a few extra GPUs.
posted by butterstick at 10:45 AM on May 28, 2013


So there are no perfect solutions to prevent passwords from being brute forced, only varying degrees of mitigation?

I mean really, a password or -phrase is just an extreme form of security through obscurity, isn't it?
posted by shakespeherian at 10:45 AM on May 28, 2013 [1 favorite]


Except, crackers know of that XKCD comic, too, and the response to "pass phrases" is a "combinator attack." Also, using common replacement characters (zero for the letter O, one for the letter i or L, $ for the letter s) are also known by crackers.
The point of that comic is that the only thing that protects you from crackers is randomness, and the way that randomness is measured is entropy, usually in bits of entropy. The advantage of a random passphrase versus a random string of characters is that it's far far easier for humans to remember a bit of entropy by constructing strange images than it is to remember strange glyphs. So if you are going to base a system on people remembering random bits, it's best for humans if those bits are encoded as standard words and imagery.

It doesn't matter that the crackers know the dice ware scheme, and the standard analysis of these schemes is to assume that an attacker knows everything about your scheme.
posted by Llama-Lime at 10:49 AM on May 28, 2013 [7 favorites]


I personally use LastPass, but I don't make any illusions about it being completely secure. It's probably less secure for me since it presents a big, tasty target for crackers, and since their database HAS to be reversible, once someone cracks their DB, all my passwords are toast.

I'm a user of LastPass as well. Certainly an independent audit would help make sure they're being truthful about their claims, but unless they're just absolutely lying, there's no reason to expect they can reverse your encrypted database. The key to each database is generated from the user's master password, which they don't have.
posted by odinsdream at 10:50 AM on May 28, 2013


So if you are going to base a system on people remembering random bits,

And this is, I think, what needs to be discarded if we are serious about online security. We need to stop basing the system on people remembering random bits, and on asking people to remember increasingly-longer random bits as technology improves.
posted by muddgirl at 10:52 AM on May 28, 2013 [2 favorites]


"[Lastpass is] probably less secure for me since it presents a big, tasty target for crackers, and since their database HAS to be reversible, once someone cracks their DB, all my passwords are toast."

That's not really true. What's stored on their side is your encrypted data. All the encryption and decryption is done client-side, meaning they never see your raw data and don't have the keys to get at it.

If a hacker does manage to dump Lastpass's database, they'll have a whole bunch of encrypted blobs of data, each one secured with a different password. They would need to brute-force every subscriber's data individually. How long that takes depends on your Lastpass password. Mine is over 30 characters, so I expect I'd be fine.
posted by CrayDrygu at 10:53 AM on May 28, 2013 [2 favorites]


So there are no perfect solutions to prevent passwords from being brute forced, only varying degrees of mitigation?

mypassword123456789 can't be reasonably brute-forced. The point of the article is that password cracking has a fair number of strategies for analyzing human behavior that allow them to break passwords they can't brute force.

Passwords with a completely random selection of characters are good. Longer passphrases are probably still good assuming random selection of words.
posted by CBrachyrhynchos at 10:54 AM on May 28, 2013


Question: what about just having thumbprint readers on every computer/mouse/keyboard and using that for identification? Or is that hackable too?

Think of it this way. How secure would your password be if you left a copy behind on everything you touched? Also: are you done with that Coke? I need to login to your account & check your email.
posted by scalefree at 11:02 AM on May 28, 2013 [4 favorites]


The point of that comic is that the only thing that protects you from crackers is randomness, and the way that randomness is measured is entropy, usually in bits of entropy. The advantage of a random passphrase versus a random string of characters is that it's far far easier for humans to remember a bit of entropy by constructing strange images than it is to remember strange glyphs.

But the point that XKCD cartoon is obscuring is that, because of dictionary attacks, the password "correct horse battery staple" isn't remotely as secure as "x8rdf9 aey5h 8ducig vmo1kw" (assuming those characters were randomly generated) and probably isn't even as secure as "x8rdf9 aey5h" even though the latter technically has enormously fewer bits of entropy.
posted by straight at 11:04 AM on May 28, 2013 [2 favorites]


Except, crackers know of that XKCD comic, too, and the response to "pass phrases" is a "combinator attack." Also, using common replacement characters (zero for the letter O, one for the letter i or L, $ for the letter s) are also known by crackers.

But that's like saying: "the response to 'randomly-generated 10 character password strings' is to generate every 10 character permutation-with-repetition using the allowed alphabet.' Passphrases effectively increase the size of the alphabet from ~50 (type-able characters) to say 5000 (working vocabulary). A random five-word passphrase is stronger than a 10-character random password. The neat thing is the unit of human memory is "things" not characters, so there's no extra cost to memorize a random passphrase over a random password.

Or what Llama-Lime said.
posted by cosmic.osmo at 11:04 AM on May 28, 2013 [3 favorites]


Passphrases effectively increase the size of the alphabet from ~50 (type-able characters) to say 5000 (working vocabulary).

But the XKCD cartoon is claiming an increase in security as if every letter of the passphrase were randomly generated, when in fact it's basically a 4-letter password using an alphabet of 5000 letters. That's not really a huge improvement over an 8- or 10-letter password using an alphabet of 50 characters.
posted by straight at 11:10 AM on May 28, 2013 [2 favorites]


Well, they used MD5 hashes in the example. That's like begging to be hacked. Use SHA2 next time!
posted by blue_beetle at 11:11 AM on May 28, 2013


Sadly, we can't control how sites encrypt our passwords, and even if there are no red flags like a service that e-mails you your password, or a length limit, you still get no indication on the user end whether the database employs MD5, bcrypt, salt, no salt, etc.
posted by Holy Zarquon's Singing Fish at 11:14 AM on May 28, 2013 [3 favorites]


Reading this article got me to write my yearly rant about ending passwords. When researching the blog post, I learned about a couple of new things:

Mozilla Persona is a serious attempt at having your browser authenticate you.

OpenID Connect is a refinement on OpenID (using OAuth 2) that is supposed to be a better product experience.

Internet history is littered with previous attempts at solving the login problem. I mean, Microsoft had a plausible solution 15 years ago. But the problem of passwords is only getting more severe, someone's eventually going to crack this nut. Some day we're going to look at a website registration demanding a password and laugh and roll our eyes at their backward, amateurish ways.
posted by Nelson at 11:16 AM on May 28, 2013 [7 favorites]


This is the really scary part:

Not only can crackers with GPUs learn your crazy password from obsolete and bad-practice MD5 hashes quickly, they can learn it from slightly more obsolete and bad-practice plaintext password files instantly. That's how good they are.
posted by edheil at 11:17 AM on May 28, 2013


using common replacement characters (zero for the letter O, one for the letter i or L, $ for the letter s) are also known by crackers.

They have known this for at least twenty years; I remember it being called "globbing" or something similar. Consider it part of every dictionary attack. The brute force attack engine takes the next word/phrase from the dictionary and tries it forwards, backwards, likely combinations of mixed case (upper first character, upper last character, alternating caps), replacing vowels with numbers, l33t sp34k cyphers, prefixed and postfixed with numbers, and a couple more variations I'm probably forgetting before moving on to the next one.
posted by ceribus peribus at 11:19 AM on May 28, 2013


How secure would your password be if you left a copy behind on everything you touched? Also: are you done with that Coke? I need to login to your account & check your email.

Also, changing your password would be a lot messier.
posted by Serf at 11:19 AM on May 28, 2013 [3 favorites]


straight: But the XKCD cartoon is claiming an increase in security as if every letter of the passphrase were randomly generated, when in fact it's basically a 4-letter password using an alphabet of 5000 letters. That's not really a huge improvement over an 8- or 10-letter password using an alphabet of 50 characters.
5000^4 = 625000000000000
50 ^ 8 = 39062500000000
Of course, Diceware is the real implementation of the random word passphrase, which is more like:
 7776^5 = 28430288029929701376
It's better than ten random alphanumeric + symbols, which is more like:
 80^10  = 10737418240000000000

posted by graftole at 11:24 AM on May 28, 2013 [4 favorites]


The XKCD comic considered each word to have 11 bits of entropy, meaning (if I understood it right) that the words would have been chosen from a list of two thousand, rather than seven thousand.
posted by reprise the theme song and roll the credits at 11:28 AM on May 28, 2013 [1 favorite]


Well, your thumb is hack-offable.

Actually, this is part of the reason that biometrics are not good as keys. Unlike a password, they cannot be reissued. If the world created a standard login based on your thumb and then I compromise the file representing your thumb you are fucked forever and that's that unless you can grow another one.

Biometrics are useful as PIN's though. For example the datacenter where my company hosts most of their servers is a high security facility shared by telecoms and banks and stuff. To get in the door there are three factors involved: weight, fingerprint and cryptocard. The cryptocard represents a key and weight+fingerprint verify that you are probably the person who is supposed to own that key. Also there are guards and stuff to make sure you aren't fucking around with the scanner, but that's a different problem.

In conclusion: security is hard.
posted by tracert at 11:28 AM on May 28, 2013 [7 favorites]


Also, changing your password would be a lot messier.

Injuries to your fingertips would be a bit of an issue, I'm assuming. You'd need some other way of authenticating that you're the same person, with an altered fingerprint, which begs the question "why not use that other way to begin with instead of slapping fingerprint-scanning hardware on every device?".
posted by jason_steakums at 11:30 AM on May 28, 2013


I've recently written a page on Password security (including XKCD/Diceware) this also summarises the features in some popular Password Managers as an aid to choosing the best tool to match your needs.
posted by Lanark at 11:31 AM on May 28, 2013 [3 favorites]


5000^4 =   625000000000000
50 ^10 = 97656250000000000
The only benefit to Diceware-style is that they are easier for some people to remember, character for character (so comparing an 80-character diceware password to a 10-character random password isn't a fair comparison, security-wise).

But we shouldn't be relying on people's memories for authentication in the first place!
posted by muddgirl at 11:31 AM on May 28, 2013


what about just having thumbprint readers on every computer/mouse/keyboard and using that for identification

Depending on the software, fingerprints range from not that secure, to a maximum entropy somewhere between 200 to 300 bits (review paper). According to Wikipaedia, that's a random password of 25-40 characters.

However, Mother Nature only gives you (at most) ten spares.
posted by bonehead at 11:32 AM on May 28, 2013


At the risk of pointing out the obvious, biometrics in no way solve the web login problem. Once the Evil Hackers steal the image of your fingerprint (or whatever) from one compromised site, they can then impersonate you at any other web site. It's possible to design protocols that don't require every web site to have a copy of your fingerprint in order to authenticate your fingerprint, but by the time you've designed that you've done the important part of improving login. The fingerprint aspect is secondary and password + security token is simpler.
posted by Nelson at 11:34 AM on May 28, 2013


Now that I look at the XKCD comic, though, it says:
1000 guesses/sec

(Plausible attack on a weak remote web service. Yes, cracking a stolen hash is faster, but it's not what the average user should worry about.)
So, I guess this was written before the Monthly Web Service User Database Compromise Festivals started.
posted by reprise the theme song and roll the credits at 11:36 AM on May 28, 2013 [1 favorite]


I use a hash-based password generator. Different password for each site, but no need to sync across all my machines because it is generated purely based on my master password.

I did try to set up OpenID at one point. Basically I got Google and Facebook talking to an OpenID identity on my own server, and gave up. The other 99% of sites I use, including Mefi, don't talk OpenID.
posted by miyabo at 11:39 AM on May 28, 2013


@muddgirl: I would say comparing a five word randomly-generated passphrase to a ten character (upper, lower, numeric, spec char) randomly-generated password is more than fair.

The key point is being randomly-generated.

Authentication requires secrets, whether those are held on a card, in your head, or by a third party.
posted by graftole at 11:42 AM on May 28, 2013


Fingerprint security? Mythbusters did it! Besides, we leave those greasy things all over the place. A little super glue and an enclosed container gets you all you need.

As far as password generation goes, drawing pictures on the keyboard using the keys as pixels is how I roll. Heck, it's so secure I could put it in this thread and I'm sure nobody could hack it.

It's a dog turd. Good luck figuring out where I drew it on the keyboard, and where all the flies are at!
posted by The Power Nap at 11:49 AM on May 28, 2013


One of the passowrds that was cracked in the article was qeadzcwrsfxv1331 which basically looks like line noise to me except for the numbers all being at the end. Unless that is a variant on some famous password I really wonder what hueristic guessed that one.

On preview: Figured it out, it's a keyboard pattern that can be typed with only the left hand so it probably appears in most custom dictionaries.
posted by Mitheral at 11:52 AM on May 28, 2013 [7 favorites]


The comparisons between diceware and random passwords are kinda moot since the vast majority of passwords/phrases are not random. The people running these cracks are not brute-forcing my diceware passphrase, or my 20-character metafilter password generated by LastPass.

What they're doing is awesome and scary automated analysis of human psychology and language. They're playing the player, not the board. They're finding new ways to exploit the human ability to create patterns, even when we don't intend to create them. The leaked password databases are a human psychology study at a scale that I wouldn't dream of trying squeak through human subjects.

As far as password generation goes, drawing pictures on the keyboard using the keys as pixels is how I roll.

Keyboard-walk algorithms are built into the current generation of password-cracking software.
posted by CBrachyrhynchos at 11:55 AM on May 28, 2013 [7 favorites]


Authentication requires secrets

If we call "posession of a token"a secret. But posession of a token isn't something I have to remember the way I have to remember a passphrase.

Websites can and have implemented systems like this. More importantly, password managers like KeePass can be set up to require a keyfile. But the dirty secret is that for 99% of websites, I don't actually care if my account is hacked. I only need two or three strong passwords - my email, and my bank account.
posted by muddgirl at 12:00 PM on May 28, 2013


what about the websites that ask me questions in addition to a password? Surely they must be secure, or do I now need to change my pet's name to ih2gwDu4%x?
posted by any major dude at 12:07 PM on May 28, 2013 [5 favorites]


what about the websites that ask me questions in addition to a password? Surely they must be secure, or do I now need to change my pet's name to ih2gwDu4%x?

Not a bad idea. See Sarah Palin email hack. Her email was accessed using the answers to questions like these.
posted by dforemsky at 12:10 PM on May 28, 2013 [2 favorites]


it's easy to implement two factor authentication when the two factors are something you know and something else you know
posted by reprise the theme song and roll the credits at 12:11 PM on May 28, 2013 [2 favorites]


change my pet's name to ih2gwDu4%x?

That's a good idea in any case.
posted by stbalbach at 12:12 PM on May 28, 2013 [11 favorites]


"On preview: Figured it out, it's a keyboard pattern that can be typed with only the left hand..."

Not only that, but it forms a lovely pattern.

"...do I now need to change my pet's name to ih2gwDu4%x?"

As long as you remember the answer, it doesn't matter what you put. Choose some new answers and memorize them. You mother's maiden name is "Quetzalcoatl." Your city of birth is "Ruth Bader Ginsburg." The name of your high school was "fhqwhgads."

Don't use those answers.
posted by CrayDrygu at 12:13 PM on May 28, 2013 [3 favorites]


The Magic Words are Squeamish Ossifrage.
posted by SteelyDuran at 12:14 PM on May 28, 2013 [1 favorite]


Even if just to confuse your veterinarian.

In response to the hash-based passwords, that does seem like the best solution that doesn't require LastPass or the like. It would be nice to find a cross-platform solution that isn't just an MD5 hashing tool, though.
posted by Holy Zarquon's Singing Fish at 12:14 PM on May 28, 2013


mother's maiden name is "Quetzalcoatl."

Don't use those answers.

Damn.
posted by reprise the theme song and roll the credits at 12:15 PM on May 28, 2013


Keyboard-walk algorithms are built into the current generation of password-cracking software.

All of you keyboard walkers- include jumps to dramatically increase the search space.
posted by Jpfed at 12:18 PM on May 28, 2013


You can have a sufficiently complicated password that it can't be hit-tested online in a reasonable time (one per site, use a password manager)

It's worth noting that password managers aren't panaceas, especially considering the difficulty of backing up their databases when changing computers/OSes, when you have to use their passwords on systems you can't install software upon, and their vulnerability as targets of malware.

The technique I use these days is inventing silly nonsense words, like "kaflibbletsmorp," that are fun to say. Of course it's only a matter of time before password crackers implement a Whimsy Walk function, but at least I've found a spot on this rung of the ever-ascending ladder between security and hackers where I can rest for a moment and have a little fun.
posted by JHarris at 12:21 PM on May 28, 2013


As long as you remember the answer, it doesn't matter what you put.

Doesn't it? If we're spending all this time trying to build secure passwords, but then it turns out our secret answers are easy to crack (even if you're not answering the question truthfully or at all), isn't that problematic? For that matter, how are secret answers stored? Are they subject to the same cryptographic standards as passwords? Should they be?
posted by chrominance at 12:22 PM on May 28, 2013 [1 favorite]


@mudgirl: If we call "posession of a token"a secret.

The token has a secret. You have the token. The token uses the secret to prove itself to the authenticating entity. It's vouching for you =). It manages a secret you cannot divulge.

I agree completely with your preference for tokens. I love how tokens make authentication easier and stronger. There usually is still a human memory aspect, though. I bet that for all the tokens you have, there's another secret you have to remember when authenticating. A PIN, for instance. Otherwise, it's hard to say that you actually are the one in possession of the token. A token that vouches for anyone who happens to have it in their hand may be as bad as a token that is easy to duplicate.

Tokens are great things, especially when they are tamper-resistant devices using good crypto under a solid PKI. "Tokens" are a lot less great when they are software you run on a phone or a laptop.
posted by graftole at 12:22 PM on May 28, 2013 [2 favorites]


Google offers two-factor authentication to Gmail, using your cellphone as the second factor. You should probably enable that for a start.

This is great if you a) have a cell phone and b) are reasonably sure it's not going to get stolen or turned off for non-payment.
posted by bilabial at 12:25 PM on May 28, 2013


scalefree: Think of it this way. How secure would your password be if you left a copy behind on everything you touched? Also: are you done with that Coke? I need to login to your account & check your email.
See Pope Guilty's comment on ATM card two-part security. It applies here, as well. In short: if someone (say, the Gubmint) was trying to hack your email specifically, an extra thumbprint security level wouldn't help much. But for anyone trying to randomly hack into anyone's accounts on a website, it would make it 11ty-bajillion times harder (approximately) to crack.
CBrachyrhynchos: What they're doing is awesome and scary automated analysis of human psychology and language. They're playing the player, not the board. They're finding new ways to exploit the human ability to create patterns, even when we don't intend to create them.
Yes, THAT is the real point here. Diceware = decent security (like parking your car on a busy, well-lit street and locking the doors). Long passwords you thought up yourself = mediocre security (leaving your car locked in the alleyway). Short passwords you thought up yourself, no matter how clever and "random" you thought you were, are terrible security (windows down, GPS within reach of the average passerby).
posted by IAmBroom at 12:25 PM on May 28, 2013


weight+fingerprint verify that you are probably the person who is supposed to own that key.

heaven help the dieter, then.
posted by mephron at 12:30 PM on May 28, 2013


graftole: Of course, Diceware is the real implementation of the random word passphrase, which is more like:

7776^5 = 28430288029929701376

It's better than ten random alphanumeric + symbols, which is more like:

80^10 = 10737418240000000000
OK, we're starting to get a bit fetishy with the numbers here. Those are effectively exactly the same degree of entropy. When you're discussing something like cracking passwords, the only number that really matters is the power of ten. They both have 10^19 entropy.

I don't want a password that is twice as safe; that's just a 6-month wait for Moore's Law (by example, but of course hacking is about more than processor speed).
posted by IAmBroom at 12:31 PM on May 28, 2013


@IAmBroom

Yep, they are pretty much the same amount of entropy (64 vs 63 bits). One is easier to remember than the other. The objective of the passphrase isn't to be far better than an incredibly strong password, but to be as strong as a strong password while far easier to remember.
posted by graftole at 12:38 PM on May 28, 2013 [2 favorites]


You can't hide secrets from the future with math...
posted by jason_steakums at 12:39 PM on May 28, 2013


"If we're spending all this time trying to build secure passwords, but then it turns out our secret answers are easy to crack (even if you're not answering the question truthfully or at all), isn't that problematic?"

Yes, but that's another topic entirely. Using false answers to security questions will neither help nor harm in that case - the most literal definition of "it doesn't matter."

It will, however, stop people who know you from easily finding the answers. Most of my friends know or can easily find "the name of your high school" or "your first pet's name" or "the color of your first car."
posted by CrayDrygu at 12:39 PM on May 28, 2013


The technique I use these days is inventing silly nonsense words, like "kaflibbletsmorp," that are fun to say. Of course it's only a matter of time before password crackers implement a Whimsy Walk function

Sadly, the Markov techniques mentioned above are essentially Whimsy Walks. BUT! If you like your whimsy, run your whimsical words through a simple post-processing step that makes Markov chains less likely to work (e.g. a Caesar cipher turns kaflibbetsmorp into lbgmjccfutnpsq, which is safely out of Markov-land).
posted by Jpfed at 12:42 PM on May 28, 2013


This is great if you a) have a cell phone and b) are reasonably sure it's not going to get stolen or turned off for non-payment.

Google actually uses Google Authenticator for the second factor; there are versions for major smartphone platforms from Google but the code is available on Google Code and IIRC there are other versions available for standard OSes.

Backup codes are made available in the case of phone loss or theft, and it's also worth noting is that once Google Authenticator is installed it doesn't require any sort of connection to keep generating codes.
posted by The Michael The at 12:43 PM on May 28, 2013 [1 favorite]


I maintain password security by not having any money or other reason for someone to get into any of my accounts.
posted by shakespeherian at 12:28 PM on May 28 [5 favorites −] Favorite added! [!]


Funny, I maintain password security by telling people I maintain password security by not having any money or other reason for someone to get into my accounts.
posted by symbioid at 12:48 PM on May 28, 2013 [1 favorite]


well poop
posted by echocollate at 1:11 PM on May 28, 2013 [1 favorite]


Well, they used MD5 hashes in the example. That's like begging to be hacked. Use SHA2 next time!

This would not dramatically change the outcome, nor would the addition of salts. The attackers weren't attempting a preimage attack or anything fancy — they just tried a lot of passwords in parallel. This works because MD5 and SHA2 are designed to be fast, especially in hardware. I wrote about how this works a while ago. (It's actually linked from the article, which made me happy.)
posted by Coda at 1:13 PM on May 28, 2013 [2 favorites]


So it seems that passwords are not the problem but 'hashes' are. This means websites need better security hashes. Why is that so hard?
posted by Rashomon at 1:20 PM on May 28, 2013


Because that means doing something different from what they're doing right now, and organizational inertia is a bitch.
posted by Holy Zarquon's Singing Fish at 1:25 PM on May 28, 2013


Why is that so hard?

Human culture and computational power are changing at different rates. Most software engineers have no idea what modern CPUs are capable of, let alone GPU-based systems like those described in the article, so the notion that the attacker would just try all the damn passwords isn't even a consideration.
posted by Coda at 1:31 PM on May 28, 2013


Ha, Coda, you were the first person I thought of with that SHA2 comment. Do you come to threads when people say "password hash" three times quickly?
posted by Nelson at 1:36 PM on May 28, 2013 [1 favorite]


One very secure way in principle is to have a public/private keypair and send the site the public key when you register. To log in, the site displays an encrypted phrase, and you put in the plaintext of that phrase.

In practice it's hard to do conveniently and without introducing way more complexity on the user side, which in turn just creates new risks to replace the old ones. You'd need your private key available and the means to use it whenever you wanted to log into the site. Which pretty much means it would need to be on your smartphone. Not everybody has one and of course, phones get stolen.
posted by George_Spiggott at 1:37 PM on May 28, 2013


I use a hash-based password generator.

Yeah, I'm really curious what people here think about this. I have (what seems to me, a total non-expert but a big Schneier fan) a pretty secure master, but the salts are pretty obvious, so it SEEMS like it would just take using the methods in the OP to generate a few rainbow tables to get a similar result….
posted by solotoro at 1:47 PM on May 28, 2013


Do you come to threads when people say "password hash" three times quickly?

Essentially, yes.
posted by Coda at 1:51 PM on May 28, 2013 [4 favorites]


Rashomon: "So it seems that passwords are not the problem but 'hashes' are. This means websites need better security hashes. Why is that so hard?"

It is up to each website to get it right, it is the user that suffers if they do it wrong, there is no way to know if they are doing it right.
posted by idiopath at 2:01 PM on May 28, 2013


It is up to each website to get it right, it is the user that suffers if they do it wrong, there is no way to know if they are doing it right.

Already such a huge problem when so many websites out there use old & busted shopping cart installations. It's a big issue when you've got a hobby that involves buying from a lot of tiny boutique stores online, there's a lot of "I need part X for project Y and only website Z carries it, but they don't take PayPal...".
posted by jason_steakums at 2:06 PM on May 28, 2013


I used to be afraid of that too, but now I basically just roll with it.

My default assumption is that every website in the world sucks and will be definitely be hacked, so I just adjust my expectations accordingly. For credit cards that means I containerize my purchases on different accounts (to spread risk), and watch my bills and that's basically good enough.

If some industrious Chinese kid hacks a shitty site and uses my card to buy a bunch of tentacle porn and guns then I say good on em. Good job, Chinese teen! You earned it. Then I call the bank and get my money back. No big deal.
posted by tracert at 2:37 PM on May 28, 2013 [1 favorite]


Today I learned that the guy who hacked Palin's email account only got a year and a day of jail time in the end of it all. Which is great; I figured he was going to Guantanomo or something when the news broke....
posted by kaibutsu at 3:01 PM on May 28, 2013


Rashomon: "So it seems that passwords are not the problem but 'hashes' are. This means websites need better security hashes. Why is that so hard?"

It is up to each website to get it right, it is the user that suffers if they do it wrong, there is no way to know if they are doing it right.
Also, both the acceptable practices and best practices for passwords are changing rather quickly, and when you combine that with engineers that either don't have the time to do their homework, or don't care to, you end up with the current situation where you might as well assume there's a >50% chance that the exact password you provide will be taken by some nefarious people in the next few years.

An example of this is the use of the very term "password hashing." Password hashing isn't even the correct technology any more, you want a "key derivation function," and one that allows you to crank up the work factor to match computing power increases. Commonly used key derivation functions are PBKDF2, bcrypt, and scrypt. And even if J Random Programmer decides to use these, they may decide to implement them on their own, in which case there's a good chance that they'll screw up the security anyways.

In the end, passwords are not the ultimate security, and for extremely valuable resources, the recourses are purely social rather than technological. Financial providers such as Fidelity and Vanguard, which hold many people's retirement nest eggs, which can easily grow into the millions of dollars, have horrifically poor limitations on their passwords which make it impossible to create a "good" password according to modern standards. And instead of upgrading their authentication systems, these financial portals just take on personal responsibility in case somebody hacks your account. At least they say they will. If you use something like Mint, then you've handed out your password to a third party, and Vanguard or Fidelity will no longer take responsibility if somebody hacks your account.
posted by Llama-Lime at 3:03 PM on May 28, 2013 [1 favorite]


Bruce Schneier: Why security training doesn't work.

I personally believe that training users in security is generally a waste of time, and that the money can be spent better elsewhere. Moreover, I believe that our industry's focus on training serves to obscure greater failings in security design.

posted by Sebmojo at 3:16 PM on May 28, 2013 [1 favorite]


...the salts are pretty obvious, so it SEEMS like it would just take using the methods in the OP to generate a few rainbow tables
posted by solotoro


A key distinction here is that the OP is talking about password encryption on a server i.e. one big password database with thousands or millions of entries all encrypted in the same way.

The output of a personal password generator is INPUT for the encryption used on the website to store/validate passwords. So an attacker would need to break the websites encryption, then recognise that the random string of characters returned are from a personal password generator, then figure out which password generator was used and then try to reverse that cryptographic hash algorithm to get to your master password.

A public salt makes it more time-consuming to crack a list of passwords. However, it does not make dictionary attacks harder when cracking a single password.

The weaknesses in MD5 have been known since 2008, it's about time they were retired.
posted by Lanark at 3:34 PM on May 28, 2013


I make a distinction between sites I don't care about, like nytimes.com, and the many others I've registered at. They all get the same password. Then Gawker got hacked, and my generic password was published. I changed it for sites I remembered, and assume the newer generic password may also be subject to getting leaked. This article has reminded me that it's time to change my email password to something longer; it's already random enough for my standards. I appreciate that Google has enabled 2 factor identification in case I need to recover my account, a not unlikely circumstance. I really, really wish my credit union and credit cards used 2 factor identification.

Computing power will continue to increase, hacking algorithms will improve, and security's a moving target. That's probably terrifyingly true of the electricity grid, other resources, and who know about the military. There's only so many things I keep on my list of stuff to stay awake about, and the list is pretty full.
posted by theora55 at 3:36 PM on May 28, 2013


Then I see that Google wants me to share my birthdate, cause it's not like that's used for security by ;lots of banks, health care providers, etc. sheesh.
posted by theora55 at 3:47 PM on May 28, 2013


google wants your birth date for marketing purposes.
posted by Mitheral at 5:12 PM on May 28, 2013 [1 favorite]


The modern way to fight hacker crunching is to use a hashed password to encrypt a text, then repeat that about 5000 times. Slows down encryption and decryption (part of the cost of doing business "securely"), but also seriously slows down hacking them.

Ultimately there's no "security". Just better and better approximations of it ... for a time.
posted by Twang at 5:44 PM on May 28, 2013


use a hashed password to encrypt a text, then repeat that about 5000 times

ARGH. No. Please stop. Just stop. This kind of "I'll make something up" is part of why we're so screwed. You're not too far off with the repeated hashing, but the details are subtle and there's absolutely no reason to re-invent this sort of hashing.

If you really have to write your own password store, Coda kindly linked his How To Safely Store A Password up-thread. tl;dr: Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt.

bcrypt isn't really a panacea either. Which is why ordinary consumer websites (like Metafilter here) should get out of the business of managing user passwords entirely. Which is why OpenID, Persona, or even Facebook Connect are all better solutions.
posted by Nelson at 5:53 PM on May 28, 2013 [5 favorites]


I just changed all my passwords to "bcrypt". Now I am safe.
posted by bxyldy at 8:57 PM on May 28, 2013 [9 favorites]


Don't use bcrypt!
posted by pwnguin at 11:15 PM on May 28, 2013 [1 favorite]


On my server I simply have a trillion decoy password files. Even if they steal them all, they don't know which one to attack. They're all identical to the real one except the plaintext for the passwords themselves is randomly generated by a HRNG.

The program that selects the correct file to use for the real passwords was made provably secure from reverse engineering by writing it in Perl.
posted by George_Spiggott at 3:51 AM on May 29, 2013 [1 favorite]


Password managers are (IMHO) the only sensible way to deal with this stuff, currently. I'm wary of services which combine password vaults with online sync (LastPass) because that seems like one huge juicy target.

I use KeePass and have my password DB require a long secure password and a key file to open.
The password DB gets sync'd to all my devices (dropbox, whatever) but the key file is never online in any form. That way even if someone gets hold of the DB there's really no way in.

The key file resides on my computers and my phone (where I can also open the DB), and is physically backed up in a few places. The biggest risk to my data is having a laptop or phone stolen - but even then they'd need to crack my password as well as figure out which key file goes with the DB, and I'm pretty sure the kind of people who deal in stolen electronics aren't the same guys with the expert hacking skills. I'd also be vulnerable to keylogging by nefarious malware installed on my machine, but I think so would everyone else.

If someone can find a hole in my strategy, I'd be happy to have it pointed out.
posted by dickasso at 5:39 AM on May 29, 2013


I mean really, a password or -phrase is just an extreme form of security through obscurity, isn't it?

Not so much, no. The security function of a password is that it is unique identifying information - only one person in all of creation should know it. The "security through obscurity" phrase isn't simply for keeping something from widespread knowledge, it's for stating that security risks aren't really risks because 'no one else knows' they exist.

Imagine a locked door, a common security system. Your password would be similar to a key. Say you discover a flaw with a locked door that if you pulled hard and fast, it will pop open without a key. "security through obscurity" is saying that since no one knows to do that, there is no need to fix the door. It's not likely that someone will walk up and yank on the door is it? How often do you see that happen? So then the issue switches from "fix the broken door" to "don't let anyone know about the broken door".


>what about just having thumbprint readers on every computer/mouse/keyboard and using that for identification

You're assuming that every user that needs to authenticate will have fingers...
nth the "this is hard" above.
posted by anti social order at 6:06 AM on May 29, 2013 [1 favorite]


So an attacker would need to break the websites encryption, then recognise that the random string of characters returned are from a personal password generator, then figure out which password generator was used and then try to reverse that cryptographic hash algorithm to get to your master password.

I don't think that's the direction for password cracking these days. Rather than imagining a master thief trying to break through your layers of security, imagine it's a case of lions and gazelles. These cracks are based on the inference that in a large enough herd, something is going to be weak enough to fall to an analytical technique. The 10% of people using passwords that can't be broken by an analytical technique is an acceptable limitation when you're getting more than half the list in under an hour, and as much as 90% with a few days work.

The second reason I think this is unlikely, is that these techniques appear to be designed for two different goals that are unrelated to attacking individual passwords (which are disturbingly easy to obtain by using the telephone for a social-engineering attack). They're tools for cases where any account is likely a useful account, and for discovering new patterns or keywords that can be fed back into the next round of attacks.
posted by CBrachyrhynchos at 6:46 AM on May 29, 2013


Pope Guilty: "I just use hunter2, on the premise that nobody could possibly be stupid enough to use hunter2, therefore it's safe to use hunter2."

Weak sauce. I use Hunter3! as my global password. SO much more secure.
posted by Samizdata at 8:35 AM on May 29, 2013


Weak sauce. I use Hunter3! as my global password. SO much more secure.

Onion Twitter Password Changed to OnionMan77
posted by odinsdream at 9:41 AM on May 29, 2013 [1 favorite]


Speaking of password obscurity, some students of mine came back from an internship explaining that all system passwords at the company they worked for began with "/!#" in order to mitigate the most common pastefails into IRC or other scripts. I may have gotten the order wrong, but you get the idea.
posted by pwnguin at 9:56 AM on May 29, 2013


That's not necessarily stupid. If they have a well-formed 24 character password, prepending it with three easily-guessable characters does not compromise the other 24.
posted by ardgedee at 11:04 AM on May 29, 2013


Oh, I wasn't calling it stupid. Just a bit of amusing obscurity tricks.
posted by pwnguin at 11:51 AM on May 29, 2013


Sorry, I misunderstood! Carry on...
posted by ardgedee at 11:53 AM on May 29, 2013


So, what I am getting here is that once hackers have a password database containing your password they probably have your password, regardless of complexity.

Wouldn't that make frequent changes of password a better strategy than increasingly complex steps to strengthen them?
posted by Artw at 1:11 PM on May 29, 2013


It says to me that we're rapidly approaching a time when human-chosen passwords are not going to secure in any way. We're not able to reliably pick or recall a password with sufficient entropy to matter. In fact, increasingly complex password "rules" only serve to make the problem worse, by training us to form passwords in a certain way, and thus making them all the more guessable.

So, effort, time and money should be put into figuring out what replaces simple passwords. Multi-factor authentication? Random-number fobs? Cross-site logins? What ever the solution is, it needs to be simple enough that people will use it, and resilient enough that it can deal with people needing new credentials. With increasing centralization, privacy concerns are going loom large as well.
posted by bonehead at 1:22 PM on May 29, 2013 [3 favorites]


So, what I am getting here is that once hackers have a password database containing your password they probably have your password, regardless of complexity.

Close- they also check combinations of elements from known passwords. So it's not just "do they have it or don't they"; it's "do they have it or something enough like it", which is why it can be worth it to try to complexify your password beyond the boundaries of what those techniques can reach.

Wouldn't that make frequent changes of password a better strategy than increasingly complex steps to strengthen them?

The problem with frequent changes is that it taxes memory, which means that simpler passwords are more likely to be chosen. Simpler password = more likely to be in their databases.
posted by Jpfed at 5:44 PM on May 29, 2013


Right, but if "cat" and "qeadzcwrsfxv1331" are just as compromised then does it matter?

I'm assuming q34dzcwr$fxv!33! doesn't fare much better.
posted by Artw at 5:48 PM on May 29, 2013


What I mean by that is, when you try to sign up for something, and it says something like "You can't use @,',!,~,*, [or ] in your password" or "your password cannot be more than 10 characters long" (or whatever) then if you have any choice in the matter you shouldn't use that product. Stuff like that is like the brightly-colored spots on venomous frogs or poisonous caterpillars, it's nature's way of saying "walk away, do not engage".

I've read so many people saying that any maximum length limit at all on passwords is bad news, and I understand that a limit like 10 characters is clearly bad as it suggests passwords are not hashed, but doesn't bcrypt have a 72 bytes limit? (pre-hashing?) And besides, wouldn't you want to put some kind of upper bound on user input?
posted by catchingsignals at 5:58 PM on May 29, 2013


Right, but if "cat" and "qeadzcwrsfxv1331" are just as compromised then does it matter?
The qeadzcwrsfxv1331 password is compromised because it's based on an easily guessed pattern; just try typing it out on a Qwerty keyboard and you'll see why. And this is not an entirely uncommon pattern, I personally know somebody that used that method to generate what appeared to a human to be random strings of letters, but actually had a lot of underlying structure. It's exactly the worst type of password, providing the appearance of strength when there is none. It's exactly the opposite problem of the the diceware/XKCD method; people who don't understand entropy will argue until they're blue in the face that 'correct horse battery staple' just has to be weaker than a password that has less randomness in it, but looks more difficult.

The only protection against the brute force guessing game is increasing the true amount of entropy (randomness) that goes into your password; it's not password length or appearance, but randomness in generation that determines password strength. Humans are really bad at generating randomness. Go ahead and pick a number between 1 and 10. You most likely picked 7, and probably did not pick 1 or 10. Ask students in a stats class to write out the results of flipping a count 500 times, and the professor will easily be able to tell who in the class actually did the assignment by flipping a coin and who faked it. PIN choices for ATMs are completely non-random; about 10% of PINs that are used are 1234, and numbers that begin 19xx (birth or event years) are far more frequent than expected by chance.

So as others have pointed out above, the game of forcing people to memorize random bits of information is just completely the wrong way to go. It's hard enough to even choose something random. Something better has to come along.
posted by Llama-Lime at 7:43 PM on May 29, 2013 [6 favorites]


Humans are really bad at generating randomness.
It's hard enough to even choose something random.


Yep. The diceware method is not secure when *you* choose 7 "random" words from a list, only when the *dice* do it.
posted by Bangaioh at 2:30 AM on May 30, 2013 [2 favorites]


catchingsignals: I've read so many people saying that any maximum length limit at all on passwords is bad news, and I understand that a limit like 10 characters is clearly bad as it suggests passwords are not hashed, but doesn't bcrypt have a 72 bytes limit? (pre-hashing?)
72 bytes is indeed limiting, but 72^62 less limiting than 10 characters (26 letters x 2 cases + 10 digits + 10 special characters = 72). 76^62 is, well, more atoms than there are in the universe. Unlikely to be crackable in our lifetimes, if ever. But still limited.
And besides, wouldn't you want to put some kind of upper bound on user input?
Why? Unless you mean something on the order of "passwords must be under 100kB in length", for memory storage issues.
posted by IAmBroom at 7:09 AM on May 30, 2013


Websites that have some short arbitrary password length limit both fustrate and amuse me. Some place I created an account recently had a 10 character limit (Oh and the all to common mistaken belief that + isn't a valid email character). I always picture their password server as being some creaky old mini computer running COBOL for authentication and they have to keep passwords short so that account information will fit on a single 80 column card.
posted by Mitheral at 8:16 AM on May 30, 2013


Mitheral, are you talking about Telus email? "The Future is Friendly." I'll say their 8-character passwords are friendly... TO EVIL.
posted by sneebler at 8:53 AM on May 30, 2013


Humans are really bad at generating randomness.

Incidentally, I have a system for human-generated randomness that represents a different point in the tradeoff in quality vs. speed: Don't think of a random number. Think of a random word. Then turn the word into a number by running the letters of the word through a suitable function (e.g. 1 if the letter is after 'm' in the alphabet, 0 otherwise; you now have a binary number).

So to get a number between 1 and 10, you can go
metafilter
0010000101 = 133
133 mod 10 = 3
I know that methods for generating random integers that use modulo arithmetic to constrain to desired range need to deal with discrepancies between the max range of the generator and the next-smallest multiple of the width of the desired range, but it's still a way better method than the intuitive method of "pick a number that doesn't seem to have any patterns to it".

To get a random number between 1 and X with this method, there's a minimum word length: you need about 3 letters for each digit of X. If you have memorized the position of each letter in the alphabet and can use that in your letter->number function (so that eg. 'q' doesn't just yield 1, it yields 17), then word lengths can be dramatically shorter.
posted by Jpfed at 8:56 AM on May 30, 2013


I don't even remember now sneebler but it wasn't Telus.

Oh, I forgot the bonus WTF of short passwords: when the site doesn't tell you what the limit is instead just keeps denying your password as invalid.
posted by Mitheral at 10:43 AM on May 30, 2013


IAmBroom: Oh I wasn't complaining about bcrypt's limit, just the advice I keep seeing is that any limit on maximum length of a password is bad, and I remember seeing a page that named and shamed sites with that problem which, most deserved it, but even sites where the limit was 50 characters were considered a problem, which... is it? Maybe they are not storing the password in plaintext, but just thought 50 was a nice round upper bound that no one would need to go over. (Maybe they were using bcrypt, and at one point they read that the limit was 55 because of a bug, so thought 50 would do...)

Why? Unless you mean something on the order of "passwords must be under 100kB in length", for memory storage issues.

But for normal use no one is going to need to go over say 100 characters for a password on the average site. Anything approaching 100kb for a password is clearly something malicious (or something has gone very wrong), right? I don't know the maths behind the key derivation functions, so maybe I'm missing something there — do they really take the same time/use the same amount of memory to complete no matter how ridiculously large the input is? Not putting a boundary on things makes me twitchy.
posted by catchingsignals at 1:47 PM on May 30, 2013


Not having any size cap on the password would probably be a vector for hackers to get access to the passwords, somehow.
posted by Holy Zarquon's Singing Fish at 2:38 PM on May 30, 2013


Holy Zarquon's Singing Fish: "Not having any size cap on the password would probably be a vector for hackers to get access to the passwords, somehow."

Not sure if you're being sarcastic, but if not: password hash functions don't care how long your password is, they'll still return the same number of bits.
posted by pwnguin at 8:27 PM on May 30, 2013 [1 favorite]


Quasi-sarcastic. Having any data field that accepts input with no upper bound on size strikes me as asking for trouble, on way or another.
posted by Holy Zarquon's Singing Fish at 9:37 PM on May 30, 2013


True. I have a hard time thinking of a good reason to limit passwords to less than, say, a thousand characters, though, since the stored hash will be the same length in any case.

Oh, I forgot the bonus WTF of short passwords: when the site doesn't tell you what the limit is instead just keeps denying your password as invalid

Well, at least that's better than the sites which accept an arbitrarily long password but only check the first 8 characters (or whatever).
posted by hattifattener at 1:36 AM on May 31, 2013 [1 favorite]


My padawan script training suggested that arbitrary-length fields are potentially bad due to the risk of buffer overflow or injection. There are other ways around this.

I'm not a security expert, but I don't see why key strengthening can't happen in the browser using a slow hash function and server-supplied salt and parameters. Instead of sending my password via SSL, what I send is PBKDF(10000,salt+password+username). The plaintext password never leaves the password field. Should an attacker get a hash database, they get a hash of a hash.

Or build SSH-style public-key authentication into the browser.
posted by CBrachyrhynchos at 7:41 AM on May 31, 2013


I'm not a security expert, but I don't see why key strengthening can't happen in the browser using a slow hash function and server-supplied salt and parameters. Instead of sending my password via SSL, what I send is PBKDF(10000,salt+password+username). The plaintext password never leaves the password field. Should an attacker get a hash database, they get a hash of a hash.

Whatever the browser sends to the server and the server accepts is effectively the password. What is the server doing with whatever the browser sends it, in your scheme?
posted by Jpfed at 8:03 AM on May 31, 2013


Jpfed: in a system like HTTP Digest auth or TLS SRP (or client certificates for that matter), the server sends a distinct challenge each time for the browser to use to compute the response; the challenge changes each time to prevent the kind of replay attack you describe. In some systems, the server never even sees enough information to impersonate the client. In others, the server does have enough information that it could impersonate that client to itself but not to any other server (even if the user is using the same password everywhere).

It's not as if there aren't good strong technical solutions to these problems. There are, and some of them are even widely deployed. It's just that (almost) nobody uses them. And the reason that nobody uses them is that nobody uses them.

(Also, increasingly, the threat model is that the client machine is fully compromised with a keylogger or whatever, in which case it doesn't matter how good your protocol is; I think in that case you basically need a hardware token.)
posted by hattifattener at 8:23 AM on May 31, 2013 [1 favorite]


Jpfed: The server potentially hashes it again and compares it with the value it has in the "password" field for the table. If the attacker gets a copy of the password table, he or she is looking at a hash of a hash, and therefore, can't efficiently use the linguistic techniques described by the article to reduce the search space. The advantage for the user is that the password strengthening happens silently in the browser. (Also by pushing the password strengthening to the client, it becomes massively distributed and you can push those algorithms to a point that make dictionary attacks unfeasible.)

It's not bulletproof, but then again nothing is. It's an idea that tries to complicate one of the tools that password crackers are using.

hattifattener: Yes, keyloggers are another threat. However, given the number of big-company database hacks that have happened in the last year, password and hash strengthening strikes me as a serious threat.
posted by CBrachyrhynchos at 8:42 AM on May 31, 2013 [1 favorite]


hattifattener: "It's not as if there aren't good strong technical solutions to these problems. There are, and some of them are even widely deployed. It's just that (almost) nobody uses them. And the reason that nobody uses them is that nobody uses them."

That's not strictly true. HTTP Digest Auth is also a terrible, unthemable UI, and I wouldn't be surprised if accessibility was also a problem. Plus, the HTTP Digest uses md5....
posted by pwnguin at 10:14 AM on May 31, 2013


ArsTechnica has now posted their guide to password managers.
posted by Llama-Lime at 10:19 AM on June 4, 2013


« Older This summer will be an exciting one for fans of re...  |  Shut Up and Listen... Newer »


This thread has been archived and is closed to new comments