Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New 25 GPU Monster Devours Passwords In Seconds

securityledger.com

Post reply on HN
Print view View original

31–40 of 91 posts

Re: New 25 GPU Monster Devours Passwords In Seconds

#31

Post by sspiff »

_b8r0 wrote: post #22

The problem with all of this is that security specialists (of which I am one, guilty as charged) have historically campaigned for more complex passwords. This worked well for conventional (non-clustered, non-accelerated) password cracking mechanisms. Sadly, this starts to fall apart with accelerated and/or distributed cracking. On average I crack a few hundred passwords a week, and more often than not organisations h…

Since reading that xkcd, I use phrases as passwords, using a simple Ruby script to generate them:

  w = File.readlines('/usr/share/dict/words').map { |w| w.chomp }.reject { |w| w !~ /^[A-Za-z]+$/ }; 3.times { print w[rand * w.size] }; puts
I generally get an easy to remember password after about 3 tries. The biggest issue I have with this is typing in passwords on mobile devices.

Re: New 25 GPU Monster Devours Passwords In Seconds

#32

Post by mrb »

rb2k_ wrote: post #19

Seeing as what kind of GPU farms people ran/run for mining Bitcoin, this is somewhat "in the middle" rather than being a "monster"

As a matter of fact, I sold 16 GPUs to Jeremi, the security research in question, and yes it was just a fraction of my Bitcoin mining farm. Your statement is true :-)

(Hi Jeremi, nice work!)

Re: New 25 GPU Monster Devours Passwords In Seconds

#33

Post by dbaupp »

nwh wrote: post #16
dave1010uk wrote: post #13

Earlier quoted context omitted.

I guess the parallelism is why botnets are so good at it. I wonder if anyone's tried getting JavaScript web workers (or possibly, somehow WebGL) to poll a central server to do cracking. A site with just a few thousand visitors a day should be able to crack passwords faster than this machine.

I have attempted this, and I believe others on the wider Internet have as well. Essentially it ended up being slower than if the central servers CPU was used to attack the hashes instead. With only JavaScript available to do the hashing, the maximum per client was disappointingly slow, around 2000 hash/second each if I remember correctly. It might be better now with faster JavaScript engines, but I wouldn't bet on it…

How long ago did you try this?

Re: New 25 GPU Monster Devours Passwords In Seconds

#34

Post by DanBC »

alexkus wrote: post #18
rorrr wrote: post #14

> That renders even the most secure password vulnerable to compute-intensive brute force No it doesn't. My passwords are 30-character randomly generated and look like this: T7PN2m7Yju43IWtoBkwL6TLx18Rdyq Do you want to guess how long it will take to bruteforce with that "monster"? (26 + 26 + 10)^30 = 5.91 × 10^53 possible combinations At 348 billion guesses per second it will take 1.53 × 10^42 seconds or 4.84 × 10^34…

True, but in reality you're probably sending that password over something less secure (like an SSL connection) that doesn't require quite as long (but still a very long time) to crack. Anything is only as secure as the weakest link in the chain. If (I'm sure you don't) you allow your browser to save that password so that you don't have to enter it every time then you just need one cleverly designed trojan to be run o…

Yes, there might be other attacks on the password, but rorr is responding directly to part of the article which claims

> Gosney’s system elevates password cracking to the next level, and effectively renders even the strongest passwords* protected with weaker encryption algorithms, like Microsoft’s LM and NTLM, obsolete.

Re: New 25 GPU Monster Devours Passwords In Seconds

#35

Post by michaelt »

peteretep wrote: post #8

The numbers are ... misleading ... and choosing NTLM hashes seems like bordering on misinformation. Taking SHA-1 (which YOU MUST NOT USE for password hashing blah), it manages 63 billion a second. To try all the passwords for that in the alphanumeric space: - 10 chars: 35 weeks - 11 chars: 44 years - 12 chars: 2,800 years - 16 chars: 11 times the age of the sun 10 chars for bcrypt: 600,000 years... http://www.wolfram…

LinkedIn used unsalted SHA-1, had their passwords leaked, and within a month 90-95% of leaked passwords were cracked[1].

Admittedly LinkedIn isn't a critical application calling for people's most secure passwords - but it's evident that only 5-10% of users use passwords that take more than 1 month to crack when hashed with SHA-1.

[1] http://securitynirvana.blogspot.co.uk/2012/06/final-word-on-...

Re: New 25 GPU Monster Devours Passwords In Seconds

#36

Post by _ikke_ »

sspiff wrote: post #31
_b8r0 wrote: post #22

The problem with all of this is that security specialists (of which I am one, guilty as charged) have historically campaigned for more complex passwords. This worked well for conventional (non-clustered, non-accelerated) password cracking mechanisms. Sadly, this starts to fall apart with accelerated and/or distributed cracking. On average I crack a few hundred passwords a week, and more often than not organisations h…

Since reading that xkcd, I use phrases as passwords, using a simple Ruby script to generate them: w = File.readlines('/usr/share/dict/words').map { |w| w.chomp }.reject { |w| w !~ /^[A-Za-z]+$/ }; 3.times { print w[rand * w.size] }; puts I generally get an easy to remember password after about 3 tries. The biggest issue I have with this is typing in passwords on mobile devices.

Aren't phrases easier to type on mobile devices than letter / number combinations? I always find it annoying to have to switch to different keyboard modes (text / numbers), or having to hold the letter / number key for a few seconds.

Re: New 25 GPU Monster Devours Passwords In Seconds

#37

Post by nemo1618 »

rorrr wrote: post #14

> That renders even the most secure password vulnerable to compute-intensive brute force No it doesn't. My passwords are 30-character randomly generated and look like this: T7PN2m7Yju43IWtoBkwL6TLx18Rdyq Do you want to guess how long it will take to bruteforce with that "monster"? (26 + 26 + 10)^30 = 5.91 × 10^53 possible combinations At 348 billion guesses per second it will take 1.53 × 10^42 seconds or 4.84 × 10^34…

Such passwords are certainly secure, but it's a pain to have to carry Keepass/other programs around when using other computers. I think I've found a happy medium by memorizing a simple password-generation function in my scripting language of choice. It produces sufficiently strong passwords, and if you're stranded without Keepass you can still generate them using a local interpreter or a site like codepad.org.

Re: New 25 GPU Monster Devours Passwords In Seconds

#38

Post by lucian1900 »

rorrr wrote: post #28
alexkus wrote: post #18

Earlier quoted context omitted.

True, but in reality you're probably sending that password over something less secure (like an SSL connection) that doesn't require quite as long (but still a very long time) to crack. Anything is only as secure as the weakest link in the chain. If (I'm sure you don't) you allow your browser to save that password so that you don't have to enter it every time then you just need one cleverly designed trojan to be run o…

> The National Institute of Standards and Technology (NIST) has issued a statement that says SSL certificates with a key length of 1,024 bits or fewer will be insufficient for security after December 31, 2010 > It is recommended that the algorithms and key sizes in the "Through 2030" row (e.g., 2048-bit RSA) should be used to provide the cryptographic protection http://csrc.nist.gov/publications/nistpubs/800-57/sp800…

I think the suggestion of SSL being less secure was based on it possibly having some vulnerability or other (which, historically, has happened), not necessarily having to brute force it.

Hashes don't tend to have side-channel attacks.

Re: New 25 GPU Monster Devours Passwords In Seconds

#40

Post by wcoenen »

nemo1618 wrote: post #37
rorrr wrote: post #14

> That renders even the most secure password vulnerable to compute-intensive brute force No it doesn't. My passwords are 30-character randomly generated and look like this: T7PN2m7Yju43IWtoBkwL6TLx18Rdyq Do you want to guess how long it will take to bruteforce with that "monster"? (26 + 26 + 10)^30 = 5.91 × 10^53 possible combinations At 348 billion guesses per second it will take 1.53 × 10^42 seconds or 4.84 × 10^34…

Such passwords are certainly secure, but it's a pain to have to carry Keepass/other programs around when using other computers. I think I've found a happy medium by memorizing a simple password-generation function in my scripting language of choice. It produces sufficiently strong passwords, and if you're stranded without Keepass you can still generate them using a local interpreter or a site like codepad.org.

This doesn't work because there are conflicting rules out there about what a password should look like. Less than X chars, more than X chars, must contain certain chars, must'n contain certain chars...

I use KeePass, with a copy (via dropbox) on my smartphone for when I'm not at my own computer.

Post reply on HN