Wednesday, June 20, 2012

Passwords Matter

This is in response to a Tenable blog post "Do Passwords Matter?"  I have several issues with the post that I address here.

Password Salts

When discussing password cracking, the post says "A 'salt' will help slow down this process a little."  Actually, salts slow down the process a lot.  It's still no more difficult to brute-force an individual user, but it becomes insanely hard to brute force all of the accounts for a large set of hashes (e.g. the 6million+ hashes dumped from LinkedIn).  With salts, it's six million times harder to crack six million passwords than to crack one.  Salts also prevent rainbow tables and other precomputation attacks completely.  The Tenable post points out that developers sometimes implement salts incorrectly.  That's really beside the point.  Just because some developers get it wrong doesn't mean the others should stop trying to get it right.

Side note: rainbow tables are not as powerful as people think they are.  Looking up a large number of users in rainbow tables is prohibitive.  They are useful for attacking one or a small number of users, but that's it.  At one minute per lookup, it would take over a decade to use an existing rainbow table against all of the LinkedIn hashes.

The post goes on to say that "even if salts are implemented correctly, the processing power of GPUs can be used to crack the salted password hashes in more time, using even larger pre-computed password dictionaries than ones without a salt."  This is utter nonsense.  With 128-bit salts (as used in bcrypt) it's impossible to create rainbow tables for all or even a significant portion of the possible salt values.

Imagine that you want to create rainbow tables for all 8 character, lower-case, alphanumeric passwords. There are about 2**41 possible combinations. Assuming no wasted computation (and making rainbow tables wastes plenty), you’d need to perform around 2**169 computations to make rainbow tables for all 2**128 salts.  If you wanted to perform a brute force attack against the 6.5m LinkedIn passwords using the same character set, you’d only need to perform about 2**64 computations. So the effort to create the rainbow tables would be 2**105 times greater than brute-force. If you had a supercomputer that could brute force 2**64 in 1 second (and for bcrypt that’s insane), the universe would die a heat death long before you finished.

Rainbow tables require anywhere from hundreds of megabytes to multiple gigabytes of storage. Currently, we can store about a terabyte on a hard drive (2**40 bytes). If you needed to store a 1 gigabyte rainbow table (or set of tables) for each salt, you’d need about 2**158 bytes of storage. That means you’d need 2**118 terabyte hard drives or 2**108 one petabyte hard drives.


Password Complexity

On the topic of password complexity, the posting points out that many users will use the weakest password allowable given the site policy.  It points out that attackers can guess billions of passwords a second using GPU hardware.  This is true and it's one of the reasons for salting and stretching passwords.  Salting forces an attacker to consider each user individually; his cracking efforts no longer scale.  For instance, if salting is used and two users both have the password "P@ssw0rd", an attacker will not be able to know that the passwords are the same and will have to guess passwords for each user separately which doubles the work effort to crack both.

With stretching, the passwords are hashed using using an algorithm that is deliberately slow (possibly by iterating a fast algorithm thousands of times as in PBKDF2).  Stretching can be used to slow down cracking so that an attacker can only guess 100 passwords per second or less on a fast CPU.  This prohibits the use of rainbow tables since an attacker can no longer brute force all possible combinations for even a moderate length password.  Instead, the attacker will have to use dictionary-based attacks.  He can still crack badly chosen passwords, but it is time consuming and would be extremely prohibitive to crack a significant number of passwords for a large site.

An attacker can improve his efforts somewhat using GPU hardware, but he still will not be able to launch a brute-force attack for any reasonable length of password.  To further cramp the attacker's efforts, developers can use a password hashing scheme such as scrypt which is designed to be "memory-hard."  This prevents the use of GPU based password crackers because they only have a limited amount of memory per processor core.


An attacker can still crack a small number of weak passwords, but with bcrypt/scrypt in place he may only be able to recover a few hundred badly-chosen passwords instead of millions.


SSL and Password Sniffing

In some cases, an attacker may be able to impersonate a site or launch a man-in-the-middle attack to allow him to harvest passwords.  But, this is generally much harder than just using SQL injection and provides less benefit to the attacker.  SQL injection is a drive-by attack that requires little persistence.  Launching an ongoing series of man-in-the-middle attacks against a large website would require an attacker to have an established presence on network of the site or its ISP.  So the attacker has to be an insider or find another way to break in before beginning this attack.  I don't want to downplay this too much because it's important to use SSL and to get it right, but the fact that some risk still exists here doesn't excuse choosing bad passwords or storing them improperly.



NTLM

NTLM sucks.  No argument.


Password Strategy

Password length doesn't matter a lot if the passwords have a clear pattern (e.g. "asdfghjkl;12345" or "LinkedInP@ssw0rd").  I played around with the LinkedIn hashes and cracked a lot of passwords that were 14-15 characters.  Passwords need to be longer and more random, not just longer.

7 comments:

  1. "Actually, salts slow down the process a lot." and "developers sometimes implement salts incorrectly. That's really beside the point. Just because some developers get it wrong doesn't mean the others should stop trying to get it right."

    Actually, that is the point. I keep hearing security folks and developers alike say "Well, if we use a salt we're okay". That's just not true, and you have to look at the bigger picture to see it. Thats like saying "We have a firewall so we're secure". There are many ways to attack a web application and steal user's credentials, just because you are using a salt and slowing down the password cracking process doesn't mean you are safe.

    "This is utter nonsense. With 128-bit salts (as used in bcrypt) it's impossible to create rainbow tables for all or even a significant portion of the possible salt values. "

    I guess it depends on how you feel about "implemented correctly", and I admit I should have been more clear on this point. Some implementations of salts allow for easier attacks, such as when a static salt or a too short of a salt is used. A 128-bit bcrypt is tough to beat, largely because its a key stretching algorithm, while providing us more security, has a negative impact on performance.

    "If you wanted to perform a brute force attack against the 6.5m LinkedIn passwords using the same character set, you’d only need to perform about 2**64 computations."

    I think that's another area where we disagree. I don't really see the value in having 6.5m user's passwords for LinkedIn, what does that let me do? Update their resumes? Okay, if I take into account password re-use, I may be able to use those passwords to login to other stuff belonging to the user which may be more interesting, like their email. However, I'm looking at this from a targeted attack (I won't say APT, promise) or penetration test. You don't need to have all the user's passwords, only the ones that matter (such as Admin, the credentials for the database, the root password to the system hosting the database). So, by owning one account, you can own them all. For example, what if I modify the code to spit out the users password in plain-text, then upload that code change? Much sneakier, and independent of whatever salt or hash method you are using :)

    ReplyDelete
    Replies
    1. Salt is not enough, period. I guess we can really agree that passwords alone is not enough in the long run either, but that's another discussion.

      We need sane password policies. We need rate-limiting to reduce the risk of online attacks. We need salting and key stretching. We need patching. We need encryption of sensitive data, not just hashing the passwords. We need user-aware systems that can detect rogue logins. And did anyone mention security awareness yet?

      As for Rainbowtables, www.freerainbowtables.com pretty much lists whats available today, at least in the open. If those tables can't crack your hash, somebody with very serious budgets could eventually be in possession of even bigger tables - but that's a different game altogether.

      And sorry to say this, but you need to get more creative and deep-dive into "our" world of passwords Paul! :-)

      What can one do with the leaked Linkedin passwords? Change your resume? No, can't even do that now. :-)

      Targeted attacks are of course of interest, remember HBGary. The likelihood of password reuse is there, the Linkedin list increases the ability to somewhat predict passwords being used at various sites. Some passwords may reveal the owner (e-mail address used as password could be an example here). Linkedin by itself is not much of a target, the other sites at which Linkedin users may also be using are of higher interest. Linkedin as a stepping stone as part of a targeted attack? Absolutely. And the list goes on....

      Delete
  2. "For instance, if salting is used and two users both have the password "P@ssw0rd", an attacker will not be able to know that the passwords are the same and will have to guess passwords for each user separately which doubles the work effort to crack both."

    Again, I don't care so much about having multiple user's passwords. What helps me, and attackers, is when people use passwords they *think* are strong, but are really short in length and really easy to include in a dictionary, such as your example above of "P@ssw0rd".

    "Instead, the attacker will have to use dictionary-based attacks. He can still crack badly chosen passwords, but it is time consuming and would be extremely prohibitive to crack a significant number of passwords for a large site."

    And there are plenty of badly chosen passwords to choose from, thanks to users who don't consider security and bad password policies. Dictionary-based attacks are fine with me, and in fact have been very successful on many different assessments. This is why I wanted people to be aware that security goes well beyond they type of hashing algorithm you are using.

    "I don't want to downplay this too much because it's important to use SSL and to get it right, but the fact that some risk still exists here doesn't excuse choosing bad passwords or storing them improperly."

    I think we agree here in that we recommend that people use good passwords, store them properly, and properly implement SSL :)

    "Password length doesn't matter a lot if the passwords have a clear pattern (e.g. "asdfghjkl;12345" or "LinkedInP@ssw0rd"). I played around with the LinkedIn hashes and cracked a lot of passwords that were 14-15 characters. Passwords need to be longer and more random, not just longer."

    Wow, I can't even believe I have to state that if you choose a long password make sure it's not two crappy passwords put together. Its almost like users go out of their way to make stuff less secure!

    Thanks so much for the feedback on my post!

    Cheers,
    Paul

    ReplyDelete
    Replies
    1. "Some implementations of salts allow for easier attacks, such as when a static salt or a too short of a salt is used."

      I think we're agreed that we need large random salts.

      "I don't really see the value in having 6.5m user's passwords for LinkedIn, what does that let me do? Update their resumes?"

      The value in having lots of accounts is being able to use them to compromise other accounts, use them for spam, use them for phishing, etc. If you forget LinkedIn for a moment and pretend the target site is a bank, then having a lot of accounts gets a lot more valuable. If you're pen testing or trying to root the site itself, then getting a lot of passwords doesn't matter. I'm going to try to address this more in my next post about threat modeling for passwords.

      "Wow, I can't even believe I have to state that if you choose a long password make sure it's not two crappy passwords put together. Its almost like users go out of their way to make stuff less secure!"

      I think you have to state it because people really do just pick "linkedinpassword". Sad.

      "Thanks so much for the feedback on my post!"

      And thanks for the feedback on mine.

      Best regards,

      Steven

      Delete
    2. And people thinking they have a strong password could, in some cases, be blamed on bad password meters. I've made 2 blog posts about that before, planning an update soon:
      http://securitynirvana.blogspot.no/2010/02/never-trust-password-meters.html
      http://securitynirvana.blogspot.no/2010/11/revisiting-password-meters.html

      Major reason for doing a new post: Dropbox zxcvbn
      http://tech.dropbox.com/?p=165

      Another subject that very few has mentioned in the wake of Linkedin & other leaks is the advice/requirement of "You must change your password now".

      Sure. Tell someone you know who is NOT a complete computer/security geek, and tell them to make a typical password. I'll bet it has a digit at the end. Ask them to change their password. Another guess: +1. Tell me I'm wrong...

      I've been looking at password history for many years - we've applied Levenshtein edit-distance metrics to measure the "distance" between each generation of passwords. Guess what? :-)

      Delete
    3. Do you have any links or posts of your own regarding edit-distance on password change? That's something I'd really never considered before. I've never picked a password related to my previous one so (self-centered...) I just assumed that wasn't something that a lot of people did.

      Delete
  3. Great Problem solved....
    ImportError: /usr/lib64/python2.6/site-packages/Crypto/Cipher/_AES.so: undefined symbol: rpl_malloc

    ReplyDelete

Understanding Scope in Go

As per my New Year's resolution, I've been learning to program in Go and reading  The Go Programming Language .   On page 141 of the...