Largest-Ever Password Study: We Are All Idiots

PornoSatan said:
Password complexity is a relic from the 90's when password cracking was popular. Doesn't really matter much these days as long as you're not using an OBVIOUSLY easy password such as 1234, and even then that's unlikely to matter unless you're being targeted specifically. Someone getting into your account is much more likely to happen now via keyloggers, not through brute forcing a weak password.
Click to expand...

How is it a relic of the 90s?

You have to talk about your threat model:

If the password is at the service layer, and that service has actively implemented a password-slowing-down-procedure, such as a maximum number of guesses, or a maximum number of guesses per unit time (eg HardForum, Diablo 3, Banks, etc), then yes, password complexity is not a huge issue. An example would be ATM passwords: the entire dictionary of 4 decimal digit passwords (ie all 10,000) could be guessed in less than a millisecond (in fact, on modern machines, it’s probably done in less than a single CPU process quanta), but you're safe because they typically have a maximum number of attempts on any one machine before requiring you to contact support proving that you're you.

If the threat model is through a service layer, but said service layer hasn't implemented any password limiting measures, then any security you get is intrinsic to the medium --and that might be significant. If you're respecting TCP communication, and that every password guess must have a request-response pair before issuing the next guess, then most passwords not in a common dictionary are probably fairly safe. Passwords in such dictionary's however, not so much. For reference, the English dictionary has on the order of 200,000 entries, and, at one password guess per hundred milliseconds (roughly the round-trip time for a high-speed connection), it would take around 6 hours to guess the entire dictionary.

If the threat model is offline, where there’s nothing but the bare encryption algorithm protecting it, (eg TLS (aka SSL), encrypted hard-drives, etc --any medium where the hacker can sniff up the data, and take it home with him to start hammering on it) then password complexity is a huge factor (granted, in most of these mediums, the password is also auto-generated for you by a slow high-entropy random number generator on your machine). In such a mode, on consumer hardware, it would take on the order of minutes to guess every single word in almost every dictionary. To be truly safe here your password must not exist in any such dictionaries --these dictionaries include non english words, common misspellings of words, number-for-character substitution, etc.

I too use Last Pass* and I like to boast about how I don’t know most of my passwords. I think Last Pass is an excellent system, though for an annoying number of things it doesn’t really help, and thus, I do, for many, invent a 10-12 character random password and force myself to memorize it, and keep a copy on last pass just in case. No disasters so far, though this solution is far from perfect

One insight I can offer is that if you understand the average threat-model, there’s a few things you can do to make your passwords secure and also moderately convenient. The threat-model for 99% of us is one of low hanging fruit: the bad guys steal/obtain access to a database containing your info (credit card, social security number, whatever), and begin bashing on it with dictionaries. If your account information still hasn’t been obtained, 99.99% will simply give up (this includes the FBI), or move on to the next record.

This means that your password doesn’t have to be in the vein of hideously unmemorable auto-generated passwords (eg “M9hXSA8z86P$”). The trick GRC came up with is simply to use just enough entropy to force yourself out of the dictionary attack model, and into a raw brute force model (ie what wheatly does in portal 2) then nobody is going to get your password. What this means is that you still need a few characters of high entropy, but that the rest can be relatively low entropy. A couple examples might be
*%N2sTakunahaarnakuni --Takunahaarnakuni is “Long time no see” in Inuktitut,
passwordsXK7s!stillKindaSuck
for the low-entropy portion of your password I’d still recommend something that isn’t on anybody’s radar, as what this model assumes is that nobody knows that you’re doing it, and that if they were to find the specifics out your passwords only as good as the low entropy portion.

@"But last pass was hacked!"
If you understand LastPass’s model then you know your data falls under the 3rd of the aforementioned threat models: your passwords themselves are encrypted by your master password (and, infact, your username, which they would thus also have to guess), and thus, given a strong enough master password, obtaining the passwords themselves from the stolen encrypted data is computationally infeasible.

gah, this wasn't meant to be an essay, sorry for the verbosity.

TL;DR unfortunatly its tough to make any assumptions about password security, sometimes you can use relatively simple ones, sometimes you absolutely cannot. Blizzard should be the former, but apparently they are not.
 
I remember when Hotmail first came into existence. My dad was able to sign up with a four character password and there were no character restrictions at all.

My tactic is to use a passwords that follow a similar pattern and are easy to remember, but are also injected with characters based on a phrase. For example, my current password is movie-based and uses "primekill" as the hint phrase for the injected characters... but based on that alone you probably couldn't guess my password. It's not dictionary listed and it meets character requirements across the board.
 
Speaking of passwords, how many people at work have like 20 different passwords, and they all expire at different intervals, and don't allow to reuse any previously used passwords?

How many of you just append a different number to the end? I do, and everyone else I work with does too. You can bet the non IT people do it too, if even we do it.

One thing I've never believed in is passwords that are forced to expire. It serves no purpose. The idea of doing it is to stop people from guessing it, but if you change it, you will either pick one that was already guessed (bonus) or pick one that was not guessed yet (back in the same boat). Brute force protection is a crucial password security feature any application should have. I believe in forcing a certain complexity, and MAYBE expire it like once a year at most, but I do not believe in constant expires. You want people to be able to remember their password and not have to write it down somewhere. When you keep forcing them to change it, they have no choice but to write it down especially in an environment where there's tons of passwords to remember.

I'm speaking more about a corporate setting, and not services like yahoo, mind you. Those rarely force you to change it.
 
the biggest concern for most users is that they use the same e-mail/password combo in so many places. Just one of those places gets hacked (Sony) and that e-mail/password combo gets applied hundreds if not thousands of financial institutions like banks or credit cards as well as major online stores.

I'm sure there's code out there that automates trying those combos. So it is feasible that combo gets thrown against the wall to see what sticks in minutes if not seconds.
 
MrWizard6600 said:
If the password is at the service layer, and that service has actively implemented a password-slowing-down-procedure, such as a maximum number of guesses, or a maximum number of guesses per unit time (eg HardForum, Diablo 3, Banks, etc), then yes, password complexity is not a huge issue. An example would be ATM passwords: the entire dictionary of 4 decimal digit passwords (ie all 10,000) could be guessed in less than a millisecond (in fact, on modern machines, it’s probably done in less than a single CPU process quanta), but you're safe because they typically have a maximum number of attempts on any one machine before requiring you to contact support proving that you're you.
Click to expand...

I don't know a lot about password security but it baffles me why places wouldn't implement such security, surely it'd be one of the best deterrents against weak password hacking. Sure, if you pick a 4 letter password from the dictionary with 2 or 3 random numbers on the end a computer might be able to guess it within a few minutes or even seconds, but it'd take thousands of attempts before it gets there. Surely it'd be easy to implement security that sees more than 1 attempt per second and 5 attempts per hour as suspicious.

Personally I have a terrible memory for passwords and such, even my bank pin numbers I have to remember by pattern rather than actual numbers (I remember the path my hand follows on the keypad, then from one card to the next I keep the same couple of patterns and just mirror, flip and reverse them). I'm one of those people that even 6 months after I've gotten a new phone number when people ask me my number I have to double check it :p
 
MrWizard6600 said:
How is it a relic of the 90s?

You have to talk about your threat model:

If the password is at the service layer, and that service has actively implemented a password-slowing-down-procedure, such as a maximum number of guesses, or a maximum number of guesses per unit time (eg HardForum, Diablo 3, Banks, etc), then yes, password complexity is not a huge issue. An example would be ATM passwords: the entire dictionary of 4 decimal digit passwords (ie all 10,000) could be guessed in less than a millisecond (in fact, on modern machines, it’s probably done in less than a single CPU process quanta), but you're safe because they typically have a maximum number of attempts on any one machine before requiring you to contact support proving that you're you.

If the threat model is through a service layer, but said service layer hasn't implemented any password limiting measures, then any security you get is intrinsic to the medium --and that might be significant. If you're respecting TCP communication, and that every password guess must have a request-response pair before issuing the next guess, then most passwords not in a common dictionary are probably fairly safe. Passwords in such dictionary's however, not so much. For reference, the English dictionary has on the order of 200,000 entries, and, at one password guess per hundred milliseconds (roughly the round-trip time for a high-speed connection), it would take around 6 hours to guess the entire dictionary.

If the threat model is offline, where there’s nothing but the bare encryption algorithm protecting it, (eg TLS (aka SSL), encrypted hard-drives, etc --any medium where the hacker can sniff up the data, and take it home with him to start hammering on it) then password complexity is a huge factor (granted, in most of these mediums, the password is also auto-generated for you by a slow high-entropy random number generator on your machine). In such a mode, on consumer hardware, it would take on the order of minutes to guess every single word in almost every dictionary. To be truly safe here your password must not exist in any such dictionaries --these dictionaries include non english words, common misspellings of words, number-for-character substitution, etc.

I too use Last Pass* and I like to boast about how I don’t know most of my passwords. I think Last Pass is an excellent system, though for an annoying number of things it doesn’t really help, and thus, I do, for many, invent a 10-12 character random password and force myself to memorize it, and keep a copy on last pass just in case. No disasters so far, though this solution is far from perfect

One insight I can offer is that if you understand the average threat-model, there’s a few things you can do to make your passwords secure and also moderately convenient. The threat-model for 99% of us is one of low hanging fruit: the bad guys steal/obtain access to a database containing your info (credit card, social security number, whatever), and begin bashing on it with dictionaries. If your account information still hasn’t been obtained, 99.99% will simply give up (this includes the FBI), or move on to the next record.

This means that your password doesn’t have to be in the vein of hideously unmemorable auto-generated passwords (eg “M9hXSA8z86P$”). The trick GRC came up with is simply to use just enough entropy to force yourself out of the dictionary attack model, and into a raw brute force model (ie what wheatly does in portal 2) then nobody is going to get your password. What this means is that you still need a few characters of high entropy, but that the rest can be relatively low entropy. A couple examples might be
*%N2sTakunahaarnakuni --Takunahaarnakuni is “Long time no see” in Inuktitut,
passwordsXK7s!stillKindaSuck
for the low-entropy portion of your password I’d still recommend something that isn’t on anybody’s radar, as what this model assumes is that nobody knows that you’re doing it, and that if they were to find the specifics out your passwords only as good as the low entropy portion.

@"But last pass was hacked!"
If you understand LastPass’s model then you know your data falls under the 3rd of the aforementioned threat models: your passwords themselves are encrypted by your master password (and, infact, your username, which they would thus also have to guess), and thus, given a strong enough master password, obtaining the passwords themselves from the stolen encrypted data is computationally infeasible.

gah, this wasn't meant to be an essay, sorry for the verbosity.

TL;DR unfortunatly its tough to make any assumptions about password security, sometimes you can use relatively simple ones, sometimes you absolutely cannot. Blizzard should be the former, but apparently they are not.
Click to expand...

I agree, limiting the number of login attempts is essential and any company or site not doing that makes everyone much worse off.
 
You must log in or register to reply here.
Back
Top