Live data from Hacker News

New 25 GPU Monster Devours Passwords In Seconds

securityledger.com

11–20 of 91 posts

Re: New 25 GPU Monster Devours Passwords In Seconds

#11
post #3

It looks like - contrary to the article - the presenters are discussing hash functions, not encryption[1]. There is a difference[2]. That said, I'd be curious to know how long it'd take a device like this to decrypt "secure" AES256 text. 1. https://hashcat.net/p12/js-sha1exp_169.pdf 2. http://stackoverflow.com/a/4948393

>That said, I'd be curious to know how long it'd take a device like this to decrypt "secure" AES256 text.

Well, according to the article it tops out at about 340 Gigahashes/second. Let's for the sake of simplicity assume it can do about 1 teraflop (10^12 operations per second, or about 2^40 operations per second). The best known attack for the full 14 round AES encryption reduces it's complexity to 2^96 instructions. So you finish this in 2^56 seconds, or about 2 billion years. I recommend you either wait for an advancement in cryptanalysis or just 30 more doublings of parallel processing power.

Re: New 25 GPU Monster Devours Passwords In Seconds

#12
For an embarrassingly parallel task like this why does there need to be any blazingly fast communication between the nodes at all?

My guess is that they've taken HashCat and not made any changes to it at all and just ran it on this virtual cluster so that it assumes that it's talking directly to each GPU/node.

For brute forcing things there's no need for fast communication between the nodes, you just split the work up into units of n seconds each and then have them poll for work from a central host. Sure it's a bit more work/complex as you're effectively running individual copies of HashCat on each node but that's just a bit of scripting and saves you the cost of Infiniband!

The Virtual Open Cluster and Infiniband solution would be much better for tasks that require lots of intercommunication between the nodes (e.g. block Lanczos of large sparse matrices) but brute forcing passwords/hashes isn't a great example.

Re: New 25 GPU Monster Devours Passwords In Seconds

#13
post #12

For an embarrassingly parallel task like this why does there need to be any blazingly fast communication between the nodes at all? My guess is that they've taken HashCat and not made any changes to it at all and just ran it on this virtual cluster so that it assumes that it's talking directly to each GPU/node. For brute forcing things there's no need for fast communication between the nodes, you just split the work u…

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.

Re: New 25 GPU Monster Devours Passwords In Seconds

#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 years
That's quite a bit longer than the age of the universe.

Re: New 25 GPU Monster Devours Passwords In Seconds

#15
post #7

Earlier quoted context omitted.

It encrypts all your passwords using AES with a 128 bit key derived from your master password (PBKDF2) [1]. This is very different to what the article is talking about, since it encrypts your passwords, but the article talks about hashing which is one-way. [1] http://help.agilebits.com/1Password3/agile_keychain_design.h...

The problem with PBKDF2 however is that if you pick a weak password it's useless. It would be better if they included an option for a key as well like other password safes do.

"The problem with INSERT-SOMETHING however is that if you pick a weak password it's useless"

When is this not the case?

Re: New 25 GPU Monster Devours Passwords In Seconds

#16
post #12

For an embarrassingly parallel task like this why does there need to be any blazingly fast communication between the nodes at all? My guess is that they've taken HashCat and not made any changes to it at all and just ran it on this virtual cluster so that it assumes that it's talking directly to each GPU/node. For brute forcing things there's no need for fast communication between the nodes, you just split the work u…

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.

Re: New 25 GPU Monster Devours Passwords In Seconds

#17
post #4

I wonder what algorithm 1Password uses, and how it would fare, compared to the other options.

If you are genuinely interested in testing your 1Password keychain, the Jumbo builds of JTR include support for the agilekeychain, and some branches (Magnum Jumbo for example) offer OpenCL support for even faster attacks.

I tried it against mine, and was significantly disappointed in how quickly even my laptop could attack it. I promptly increased the complexity of my master password.

Re: New 25 GPU Monster Devours Passwords In Seconds

#18
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 on your machine (probably easier to do than waiting 4.84E34 years to crack a password) to grab the saved passwords cache from your browser and it's no longer secret.

Post reply on HN