This is a staging forum for AgileBits, not an official support forum. Visit http://discussions.agilebits.com instead.

ZDNet Article: Cheap GPUs Rendering Strong Passwords Useless

Steve G.
edited June 2011 in Lounge
In summary, software developers need to start thinking about moving away from single factor authentication (SFA) to multi factor authenticate (MFA) in the very near team and start to implement it in their products.



[indent]"Take a cheap GPU (like the Radeon HD 5770) and the free GPU-powered password busting tool called 'ighashgpu' and you have yourself a lean, mean password busting machine. How lean and mean? Working against NTLM login passwords, a password of 'fjR8n' can be broken on the CPU in 24 seconds, at a rate of 9.8 million password guesses per second. On the GPU, it takes less than a second at a rate of 3.3 billion passwords per second. Increase the password to 6 characters (pYDbL6), and the CPU takes 1 hour 30 minutes versus only four seconds on the GPU. Go further to 7 characters (fh0GH5h), and the CPU would grind along for 4 days, versus a frankly worrying 17 minutes 30 seconds for the GPU."[/indent]

Reference: http://it.slashdot.org/story/11/06/05/2028256/Cheap-GPUs-Rendering-Strong-Passwords-Useless



NOTE: 3.3 billion passwords per second on a GPU!!! The program mentioned above cracked a pretty complex 7 characters long password in 17 minutes and 30 seconds! In my opinion, I concur with the story line's title that this pretty much renders "strong passwords" (whatever your definition of this is) useless. So, you double the length of the password to 14 characters. The result? Just a few more days/weeks work for the GPU to eventually crack it? Any mathematicians out there who can reply with the correct formula for determining this? I can't remember what it is from my wireless security class where we talked about password cracking timelines based upon the passwords guess per minute.



Additionally, at some point a user isn't going to create a more complex/longer password for a variety of reasons that include:



1) I can't remember it because it is too long, so I just won't try to create one beyond 8 characters and if policy states that I must do so, I'll write it down (even riskier!).

2) I don't want to type in a "strong" 20 character master password 10 times throughout the day to gain access to my keys on the keychain. The argument being "it's just too much of a pain" when I mess up one or more characters and have to make 3 or 4 attempts to get it right.

3) Assuming I do eventually memorize it, I won't change it often because it was so difficult to commit to memory in the first place. In reality, if my data has already been stolen, it (changing your password/passphrase regularity) doesn't matter. The hacker is going to brute force your OLD password/passphrase. Only new/modified/deleted data placed on the keychain will be protected by the new password.



This story highlights why I believe it's time for companies such as AgileBits, Inc. to move their products away from SFA in a hurry! Why? Because with multi factor verification/authentication, the hacker physically needs the "thing I have" (ie. USB crypto device) in order to compromise/crack my private/encrypted data. You can't just rely on stealing the data and brute forcing my SFA password/passphrase.

Comments

  • khad
    khad Social Choreographer
    edited June 2011
    Welcome to the forums, Steve! Thanks for sharing that ZDNet article.



    I am a bit tired at the moment but wanted to make sure you know we saw your post.



    Before we have a chance to reply in full, I just want to make sure that everyone else who comes across this thread knows that [url="http://blog.agilebits.com/2011/05/defending-against-crackers-peanut-butter-keeps-dogs-friendly-too/"]this is nothing new[/url] and there is no need to panic. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



    I'll try to summon our resident Defender Against the Dark Arts to provide a more detailed response. But here are some links which may be helpful to you before we have a chance to write more:



    [list][*][url="http://en.wikipedia.org/wiki/Salt_(cryptography)"]cryptographic salting[/url][*][url="http://en.wikipedia.org/wiki/Key_derivation_function"]key derivation functions[/url]…[*]…such as [url="http://en.wikipedia.org/wiki/PBKDF2"]PBKDF2[/url] (which 1Password uses)[*][url="http://forum.agile.ws/index.php?/topic/4660-lastpass-hack-is-1pw-vulnerable/page__view__findpost__p__26544"]a previous thread on a similar topic[/url][/list]

    Thanks for asking about this. It is great that you are thinking about these things!



    Cheers,
  • jpgoldberg
    jpgoldberg Agile Customer Care
    Hi Steve, great question1



    I've been waiting for someone to ask about this.



    The source for the article is a study of off-line cracking against NTLM passwords Unfortunately it doesn't make it clear whether these were NTML version 1 or NTML version 2. This makes it difficult for me to be more precise in what follows. But both versions of NTML take only limited measures to hinder off-line password cracking should the NTLM hash database on the server get into the hands of the bad guys. Thus, off-line password cracking against a stolen database it is going to be very quick.



    From the very beginning we designed the 1Password data format to withstand attack should it fall into the wrong hands. Khad already mentioned a recent blog post describing [url="http://blog.agilebits.com/2011/05/defending-against-crackers-peanut-butter-keeps-dogs-friendly-too/"]how 1Password uses PBKDF2[/url].



    I can only speculate about the design decisions behind NTLM, but in Microsoft's defense there has been the generally held belief that "if the server is compromised to the extent that an attacker can get as the password hash database, then all is lost anyway." That kind of thinking has been behind the fact that so many recent breaches (Sony, Gawker, etc) have had user password data poorly encrypted (or in Sony's case, not encrypted at all.) What is wrong about that way of thinking is that a user's password on a site does more than get into that particular (already compromised) site, but is often [url="http://blog.agilebits.com/2011/06/two-thirds-of-web-users-re-use-the-same-passwords/"]used for other things[/url] as well. So it is important to protect users' passwords even if the entire site is compromised.



    Anyway, rest assured that we have been following developments in password cracking technology very carefully. (It's not only GPUs we worry about; but cheap, rentable "clusters" of GPUs and CPUs on cloud computing farms.) In the next day or two, I will provide some tips on how to improve your 1Password master password as well.



    Cheers,



    -j
  • jpgoldberg
    jpgoldberg Agile Customer Care
    edited June 2011
    Steve,



    Let me also add that we are certainly exploring various ideas similar to what you raise about securing your 1Password data. But other than saying that we are, and have been, discussing things, I can say very little. I'm sorry that I can't be more informative at this point, but we are certainly not ignoring suggestions like yours; we are just being quiet.



    Cheers,



    -j

Leave a Comment

Rich Text Editor. To edit a paragraph's style, hit tab to get to the paragraph menu. From there you will be able to pick one style. Nothing defaults to paragraph. An inline formatting menu will show up when you select text. Hit tab to get into that menu. Some elements, such as rich link embeds, images, loading indicators, and error messages may get inserted into the editor. You may navigate to these using the arrow keys inside of the editor and delete them with the delete or backspace key.