![]() |
| Picture from EFF -- CC-BY license |
Showing posts with label password. Show all posts
Showing posts with label password. Show all posts
Sunday, April 15, 2018
Let's stop talking about password strength
Wednesday, August 22, 2012
Common misconceptions of password cracking
After this great article on passwords at Ars Technica, I've seen some common misconceptions pop up. I thought I'd clarify them (even though that article adequately covers many of this, people seem to have missed them).
MD5 is broken, use SHA1 instead
MD5 isn’t broken as far as passwords are concerned. Sure, it has “collision” problems, making it unsuitable for signing things (such as certificates), but that really has nothing to do with passwords. Thus, MD4, MD5, SHA1, SHA2, SHA3 are all roughly equally secure as far as passwords are concerned.
Because SHA1 is cryptographic that means it’s secure
Hash functions are designed to be fast, which means they make password cracking fast. But for logins, there is no need to be fast. You want slow algorithms to make password cracking slower. Algorithms, like scrypt, bcrypt, or PBKDF2 will be better for passwords.
In other words, for protecting passwords, a cryptographic algorithm is necessary, but not sufficient.
Rainbow-Tables
Most mentions of Rainbow Tables are a misconception. After every major password breach, like the recent LinkedIn incident, numerous cybersec “experts” make the claim that they “should use salts to stop Rainbow Tables”. That’s nonsense.
In the LinkedIn case, a single 7 letter password can be cracked in minutes, an 8 character password in a day, and a 9 letter password in months. A rainbow-table doesn’t make finding that 7 letter password any faster, and rainbow-tables don’t exist for 9 letter passwords (using upper/lower/digit/symbol). It would only speed cracking of that 8 letter password from a day down to a few minutes. Sure, rainbow-tables help, but not as much as you’d think.
Rainbow-tables have their uses. Bitweasil, for example, is doing some cool things with them (like web-tables and much better GPU acceleration). But mostly when people mention rainbow-tables, it’s because they are repeating a misconception.
Salt is a magic pixie dust to secure passwords (from Steven Alexander)
As mentioned above, salt makes only a small difference stopping rainbow-tables. The major effect it has is stopping that "mass crack", like cracking millions of LinkedIn passwords all at once. But if the hacker is targeting a single password, salt makes little difference at all. Yes, passwords should be salted, but no, don't imagine that it's sufficient. What's far more important is whether they used scrypt, bcrypt, or PBKDF2, not whether they used salt.
Online vs. offline password guessing
When we talk about cracking passwords, we mean “offline” cracking. We mean hacking into a website, stealing their password database, and trying to decrypt the passwords (by guessing potential passwords and seeing if the hashes match).
Guessing passwords online, such as using a tool that sends passwords at the target, means we can guess maybe 100 passwords per second. Guessing offline means doing a BILLION passwords per second.
Moreover, many sites defeat online guessing by disabling access for a time after too many failed attempts. No such mechanism exists for slowing down offline cracking (other than using the scrypt/bcrypt algorithms to slow cracking).
Just as secure as they’ve always been
In the past few years, password crackers have jumped forward a huge amount. They now use GPUs and FPGAs to jump forward a few years ahead of expected Moore’s Law increases. Most importantly, all these massive password dumps like LinkedIn and RockYou have taught crackers what patterns to look for, making their guesses much better. Thus, your password has gotten a lot less secure in the past few years.
Amazon EC2 will defeat passwords
Not really, as I explain here and here.
Brute-forcing passwords is an exponential problem. That means having 100 times more compute power just means you can crack an 8 character password in the time you would’ve taken to crack a 7 character password. It doesn’t mean 100 times better password cracking.
Amazon EC2 economics are not designed for integer compute. The economics are not there. For the average hacker or pentester, a good GPU will be vastly better. Amazon EC2 really only makes sense in an emergency, when you absolutely have to crack something faster than it takes to go to the store and buy up all the GPUs.
GPUs are oodles faster than CPUs
Yes, but not as much as you’d hope. Like I explain above, brute-force cracking is an exponential problem, so doubling your cracking speed has a tiny improvement on effectiveness. Buying the latest GPU is useful, the marginal gains are large for the price, but the marginal benefits of buying even a second GPU are small.
Here’s a password hash; how long will it take you to crack it?
This isn’t how things work. We crackers sort our efforts according to effectiveness. We’ll try the most effective methods first, and if they fail, choose less and less effective methods. If your target chose a secure password, then I’m never going to be able to crack it.
Given a single cryptographic hash algorithm (MD5, SHA1, MD4), it’s a 30% chance I’ll find it in a few minutes, and 90% chance I’ll find it after a couple of days. As time goes on, the chance I’ll find the password keeps going down, so if I haven’t found it after a day, it’s unlikely I’ll discover the password even after a year. (It's a 'long tail' distribution)
Password meters (from Pers Thorsheim)
Many websites have some sort of "password meter" to show the "strength" of your password. While they certainly point out "weak" passwords, just because they claim your password is strong doesn't make it so. Don't believe them.
Links:
http://securitynirvana.blogspot.com/2010/02/never-trust-password-meters.html
http://securitynirvana.blogspot.com/2010/11/revisiting-password-meters.html
Password requirements
Many websites have password requirements, like forcing you to include numeric digits or upper/lower case. These have only limited utility, as many people choose predictable patterns, like appending '1' to the end of the password to meet the requirement.
Curiously, by reducing the search space, such requirements can sometimes help the attacker.
Password strength (from XKCD)
Uncrackable passwords (from XKCD)
MD5 is broken, use SHA1 instead
MD5 isn’t broken as far as passwords are concerned. Sure, it has “collision” problems, making it unsuitable for signing things (such as certificates), but that really has nothing to do with passwords. Thus, MD4, MD5, SHA1, SHA2, SHA3 are all roughly equally secure as far as passwords are concerned.
Because SHA1 is cryptographic that means it’s secure
Hash functions are designed to be fast, which means they make password cracking fast. But for logins, there is no need to be fast. You want slow algorithms to make password cracking slower. Algorithms, like scrypt, bcrypt, or PBKDF2 will be better for passwords.
In other words, for protecting passwords, a cryptographic algorithm is necessary, but not sufficient.
Rainbow-Tables
Most mentions of Rainbow Tables are a misconception. After every major password breach, like the recent LinkedIn incident, numerous cybersec “experts” make the claim that they “should use salts to stop Rainbow Tables”. That’s nonsense.
In the LinkedIn case, a single 7 letter password can be cracked in minutes, an 8 character password in a day, and a 9 letter password in months. A rainbow-table doesn’t make finding that 7 letter password any faster, and rainbow-tables don’t exist for 9 letter passwords (using upper/lower/digit/symbol). It would only speed cracking of that 8 letter password from a day down to a few minutes. Sure, rainbow-tables help, but not as much as you’d think.
Rainbow-tables have their uses. Bitweasil, for example, is doing some cool things with them (like web-tables and much better GPU acceleration). But mostly when people mention rainbow-tables, it’s because they are repeating a misconception.
Salt is a magic pixie dust to secure passwords (from Steven Alexander)
As mentioned above, salt makes only a small difference stopping rainbow-tables. The major effect it has is stopping that "mass crack", like cracking millions of LinkedIn passwords all at once. But if the hacker is targeting a single password, salt makes little difference at all. Yes, passwords should be salted, but no, don't imagine that it's sufficient. What's far more important is whether they used scrypt, bcrypt, or PBKDF2, not whether they used salt.
Online vs. offline password guessing
When we talk about cracking passwords, we mean “offline” cracking. We mean hacking into a website, stealing their password database, and trying to decrypt the passwords (by guessing potential passwords and seeing if the hashes match).
Guessing passwords online, such as using a tool that sends passwords at the target, means we can guess maybe 100 passwords per second. Guessing offline means doing a BILLION passwords per second.
Moreover, many sites defeat online guessing by disabling access for a time after too many failed attempts. No such mechanism exists for slowing down offline cracking (other than using the scrypt/bcrypt algorithms to slow cracking).
Just as secure as they’ve always been
In the past few years, password crackers have jumped forward a huge amount. They now use GPUs and FPGAs to jump forward a few years ahead of expected Moore’s Law increases. Most importantly, all these massive password dumps like LinkedIn and RockYou have taught crackers what patterns to look for, making their guesses much better. Thus, your password has gotten a lot less secure in the past few years.
Amazon EC2 will defeat passwords
Not really, as I explain here and here.
Brute-forcing passwords is an exponential problem. That means having 100 times more compute power just means you can crack an 8 character password in the time you would’ve taken to crack a 7 character password. It doesn’t mean 100 times better password cracking.
Amazon EC2 economics are not designed for integer compute. The economics are not there. For the average hacker or pentester, a good GPU will be vastly better. Amazon EC2 really only makes sense in an emergency, when you absolutely have to crack something faster than it takes to go to the store and buy up all the GPUs.
GPUs are oodles faster than CPUs
Yes, but not as much as you’d hope. Like I explain above, brute-force cracking is an exponential problem, so doubling your cracking speed has a tiny improvement on effectiveness. Buying the latest GPU is useful, the marginal gains are large for the price, but the marginal benefits of buying even a second GPU are small.
Here’s a password hash; how long will it take you to crack it?
This isn’t how things work. We crackers sort our efforts according to effectiveness. We’ll try the most effective methods first, and if they fail, choose less and less effective methods. If your target chose a secure password, then I’m never going to be able to crack it.
Given a single cryptographic hash algorithm (MD5, SHA1, MD4), it’s a 30% chance I’ll find it in a few minutes, and 90% chance I’ll find it after a couple of days. As time goes on, the chance I’ll find the password keeps going down, so if I haven’t found it after a day, it’s unlikely I’ll discover the password even after a year. (It's a 'long tail' distribution)
Password meters (from Pers Thorsheim)
Many websites have some sort of "password meter" to show the "strength" of your password. While they certainly point out "weak" passwords, just because they claim your password is strong doesn't make it so. Don't believe them.
Links:
http://securitynirvana.blogspot.com/2010/02/never-trust-password-meters.html
http://securitynirvana.blogspot.com/2010/11/revisiting-password-meters.html
Password requirements
Many websites have password requirements, like forcing you to include numeric digits or upper/lower case. These have only limited utility, as many people choose predictable patterns, like appending '1' to the end of the password to meet the requirement.
Curiously, by reducing the search space, such requirements can sometimes help the attacker.
Password strength (from XKCD)
Uncrackable passwords (from XKCD)
Pentesters: Amazon EC2 or GPUs for password cracking?
Q: Should pentesters use Amazon EC2 to crack passwords? A: Probably not.
Tuesday, August 21, 2012
The deal with passwords
Over at Ars Technica, Dan Goodin has written a comprehensive overview of the state-of-the-art of password cracking. Even if you think you understand passwords, you probably have many misconceptions that this article will dispel.
Passwords are far more complex than you think. Take, for example, this comment where somebody points out "MD5 would be an example of a hash algorithm that is no longer secure". Most people agree with that statement, they are all wrong. MD5 is just as good for hashing passwords as SHA1, or whatever appears as SHA3. The weakness MD5 has today is in "collisions", which don't matter for hashing passwords. Moreover, cryptographic hashes are designed to be fast, meaning that password cracking is fast. Better algorithms would be slow, like scrypt, bcrypt, or pbkdf2. A salted password using 10000 iterations of MD5 is still more secure than a single SHA1 hash.
Another issue is the "exponential wall", which is shown in the following graph (CC attribute license):
For brute-forcing passwords, people imagine that GPUs or Amazon EC2 clusters will make a massive difference. As the graph shows, they really don't. Short passwords are trivial to crack, even with the resources of an iPhone. Long passwords are impractical to crack, even with a billion dollar NSA supercomputer.
More hardware can make some difference because most passwords are around 7 to 8 characters, which is right in the sweet spot where added hardware will make a difference. However, what makes a bigger difference is skill, having the right wordlists of known passwords and exploiting patterns in how people choose passwords. A skilled cracker with an iPhone will crack more passwords than you can brute-forcing with an Amazon EC2 cluster. Combining skill with more hardware is even better, because the skilled person knows how to exploit the additional hardware in ways other than simply brute-forcing.
In conclusion, I highly recommend reading Dan's article. It defines the state-of-the-art of password cracking as of 2012.
Passwords are far more complex than you think. Take, for example, this comment where somebody points out "MD5 would be an example of a hash algorithm that is no longer secure". Most people agree with that statement, they are all wrong. MD5 is just as good for hashing passwords as SHA1, or whatever appears as SHA3. The weakness MD5 has today is in "collisions", which don't matter for hashing passwords. Moreover, cryptographic hashes are designed to be fast, meaning that password cracking is fast. Better algorithms would be slow, like scrypt, bcrypt, or pbkdf2. A salted password using 10000 iterations of MD5 is still more secure than a single SHA1 hash.
Another issue is the "exponential wall", which is shown in the following graph (CC attribute license):
For brute-forcing passwords, people imagine that GPUs or Amazon EC2 clusters will make a massive difference. As the graph shows, they really don't. Short passwords are trivial to crack, even with the resources of an iPhone. Long passwords are impractical to crack, even with a billion dollar NSA supercomputer.
More hardware can make some difference because most passwords are around 7 to 8 characters, which is right in the sweet spot where added hardware will make a difference. However, what makes a bigger difference is skill, having the right wordlists of known passwords and exploiting patterns in how people choose passwords. A skilled cracker with an iPhone will crack more passwords than you can brute-forcing with an Amazon EC2 cluster. Combining skill with more hardware is even better, because the skilled person knows how to exploit the additional hardware in ways other than simply brute-forcing.
In conclusion, I highly recommend reading Dan's article. It defines the state-of-the-art of password cracking as of 2012.
Monday, March 26, 2012
That doesn't mean your employer can use your Facebook password
As a Libertarian, I of course believe that employers are free to ask for your Facebook password, and that you are free to refuse. This also could be because I'm a conceited jerk who believes that any employer would be lucky to hire me, so I believe I have the upper hand in the power struggle.
But completely separate from that, giving your employer your Facebook password does not give them the right to use the password. In fact, using the password to logon could be considered a crime, such as "computer fraud and abuse" or "identity theft".
Facebook's current legal terms say this:
That means you are in violation of those terms if you give your password to your prospective employer. But, hypothetically, Facebook could add to their terms:
This makes it clear that logging into somebody else's account is identity theft, which means employers can be prosecuted under existing fraud and abuse laws. Facebook could just monitor multiple logins from a single location of unrelated accounts, and then send the police to go arrest the employer.
Of course, employers can respond by insisting that users log onto their own accounts during the interview process, but this is still an improvement. Presumably if one employer rejects you because those drunken nude party photos, you could remove them before the next job interview.
But completely separate from that, giving your employer your Facebook password does not give them the right to use the password. In fact, using the password to logon could be considered a crime, such as "computer fraud and abuse" or "identity theft".
Facebook's current legal terms say this:
You will not share your password, (or in the case of developers, your secret key), let anyone else access your account, or do anything else that might jeopardize the security of your account.
That means you are in violation of those terms if you give your password to your prospective employer. But, hypothetically, Facebook could add to their terms:
A account may be accessed only by its owner, by logging in you agree that you are the person who owns the account.
This makes it clear that logging into somebody else's account is identity theft, which means employers can be prosecuted under existing fraud and abuse laws. Facebook could just monitor multiple logins from a single location of unrelated accounts, and then send the police to go arrest the employer.
Of course, employers can respond by insisting that users log onto their own accounts during the interview process, but this is still an improvement. Presumably if one employer rejects you because those drunken nude party photos, you could remove them before the next job interview.
Wednesday, January 04, 2012
Passwords: uniqueness, not complexity
Hacktivists recently broke into the StratFor website and dumped details of 800,000 accounts, including e-mail addresses and password-hashes. Since the password-hashes were simple MD5, it meant that almost all the passwords were easily cracked. People have looked at the passwords, and found that most people chose simple ones, such as "password123". This has led to articles like this one (Breach shows that even experts chose bad passwords) that claims "Security experts recommend building long, complex, case-sensitive passwords with multiple characters".
Nope. That's wrong advice. Your password for a free or cheap StratFor account doesn't need to be complex, because there is little to lose if hackers guess it.
Instead, what's important is that the password be unique. Most sites are like StratFor and have poor cybersecurity. (StratFor wasn't even close to good cybersecurity, they were horrible on almost any measure). Any information you give them, such as your password, will eventually get stolen by hackers. If you use the same password for all websites, then eventually hackers will break into one of those sites, then gain access to all your other accounts.
Nope. That's wrong advice. Your password for a free or cheap StratFor account doesn't need to be complex, because there is little to lose if hackers guess it.
Instead, what's important is that the password be unique. Most sites are like StratFor and have poor cybersecurity. (StratFor wasn't even close to good cybersecurity, they were horrible on almost any measure). Any information you give them, such as your password, will eventually get stolen by hackers. If you use the same password for all websites, then eventually hackers will break into one of those sites, then gain access to all your other accounts.
Wednesday, August 17, 2011
Validity of most-common-password lists
As this tweet asks: what's the validity of the various lists of the most common passwords people choose, such as this one http://www.whatsmypass.com/the-top-500-worst-passwords-of-all-time.
The answer is: it depends. If you dump the passwords at the average website, you'll see these as common passwords.
But they may not reflect passwords chosen for important sites, like corporations or banking. The less important a site, the poorer the passwords. People will choose poor passwords for something like Sony Playstation gaming than they would for their corporate account. This is especially true when your corporate account enforces rules for password complexity and reset.
The answer is: it depends. If you dump the passwords at the average website, you'll see these as common passwords.
But they may not reflect passwords chosen for important sites, like corporations or banking. The less important a site, the poorer the passwords. People will choose poor passwords for something like Sony Playstation gaming than they would for their corporate account. This is especially true when your corporate account enforces rules for password complexity and reset.
Wednesday, June 22, 2011
Password cracking, mining, and GPUs
People imagine that sophisticated hacking requires sophisticated computers. The truth is that almost everything a hacker does can be done with a cheap notebook computer, or even a mobile phone.
The major exception is password cracking, and related crypto tasks like bitcoin mining and certificate forgery. In these cases, a minor investment in hardware can be warranted.
In particular, those who need to crack passwords (pen-testers, sysadmins, hackers) should buy a gaming graphics card in order to speed up cracking. Or, when buying notebooks for pen-testing, they should choose those with graphics processors.
The major exception is password cracking, and related crypto tasks like bitcoin mining and certificate forgery. In these cases, a minor investment in hardware can be warranted.
In particular, those who need to crack passwords (pen-testers, sysadmins, hackers) should buy a gaming graphics card in order to speed up cracking. Or, when buying notebooks for pen-testing, they should choose those with graphics processors.
Thursday, April 02, 2009
GPU cracking for $250

ATI and nVidia have just shipped their spring refresh cards. Both now sell an essentially top-of-the-line card for $250 (either the ATI HD 4590 or the nVidia GTX 275). If you do password cracking for pentests, you might want to pick up a few of these cards.
Both would be an excellent card to buy for password cracking. Either would increase password cracking speed by around 10x. I prefer the nVidia card because the CUDA programming support is easier to work with, but I suspect the ATI card may be slightly faster for crunching numbers.
Note the way I say "top-of-the-line". For graphics, the more expensive GTX 285 is better than the GTX 275. However, both cards have the same number of "stream processors" at roughly the same clock speed. Therefore, both should crack passwords at the same speed. What makes the GTX 275 cheaper is the fact that it less backend graphics resources (fewer raster units, slower memory speed, narrower memory bandwidth, smaller frame buffer). We don't care about these other graphics resources -- all we care about is the number of "stream processors" and how fast they run.
Subscribe to:
Posts (Atom)





