8 ms·

New 25 GPU Monster Devours Passwords In Seconds

111 points by _ikke_ 14y ago

JungleGymSam 14y ago
Exciting to see the technology behind this field progressing so quickly but troubling considering the passwords my users likely use. Though to be completely realistic their password hashes are very likely already known.
Sam_Odio 14y ago
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 https://hashcat.net/p12/js-sha1exp_169.pdf 2. http://stackoverflow.com/a/4948393 http://stackoverflow.com/a/4948393
- _ikke_ 14y ago
  Passwords shouldn't be encrypted anyway. Chances are hackers will be able to obtain the key too, and then passwords are really easy to fetch. Passwords should be hashed non-reversible (ideally using a slow hash). The original password is to no use of the application. And sending plain-text passwords to users is even more bad[1]. [1]: http://plaintextoffenders.com/ http://plaintextoffenders.com/
- archgoon 14y ago
  >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.
akulbe 14y ago
I wonder what algorithm 1Password uses, and how it would fare, compared to the other options.
- mileswu 14y ago
  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.html http://help.agilebits.com/1Password3/agile_keychain_design.h...
  - xorgar831 14y ago
    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.
    - dfc 14y ago
      "The problem with INSERT-SOMETHING however is that if you pick a weak password it's useless" When is this not the case?
      - schlomie28 14y ago
        When you have a key as well.
    - DanBC 14y ago
      > It would be better if they included an option for a key as well like other password safes do. I would love to see research about the use of keys and passphrases. Especially, do people who have a key then chose a weaker master password?
- nwh 14y ago
  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.
mileswu 14y ago
“I was extremely disappointed that setting up a clustered VMware instance wouldn’t allow me to create a VM that spanned all the hosts in the cluster. E.g. if i had five VMware ESX hosts with 8 processor cores, I wanted to be able to create a single vm with 40 cores and use all nodes in the cluster,” he wrote. Not sure why he would have thought this would be possible. This would be an extremely hard problem given the latency involved between different nodes. Then he came across VCL, or Virtual Open Cluster... “It did just what I wanted, not with an entire OS per se, but with an entire OpenCL application. and that’s good enough for me.” A similar (but far older) system is MPI[1], which enables parallel computation across many compute nodes for your code by providing message passing. It's kind of a pain to use in my limited experience since you have to adapt your code (it seems like VCL is transparent for OpenCL programs), but it does work. No need for OpenCL, tho of course you could always use OpenCL + MPI. A common thing I see is MPI+OpenMP (for parallel cpu computation). [1] https://en.wikipedia.org/wiki/Message_Passing_Interface https://en.wikipedia.org/wiki/Message_Passing_Interface
peteretep 14y ago
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.wolframalpha.com/input/?i=%2865**16+%2F+63+billion%29+seconds http://www.wolframalpha.com/input/?i=%2865**16+%2F+63+billio...
- ErrantX 14y ago
  Absolutely; NTLM has been attackable for ages. Running on a Quad core machine it can be cracked in a reasonable amount of time. The cost/time trade-off for such cracking makes this rig pointless for such cracking, unless you absolutely must have it in 6 minutes. I don't see any other major use for this; it's simply not powerful enough to attack anything new (Edit: even with 128, rather than 25, GPU's).
- mrb 14y ago
  I don't think this is misinformation. You would be surprised at the number of IT people who have no clue how fast NTLM hashes can be brute-forced. Spreading this knowledge is good. Ranting about NTLM, I am also shocked at how many people are unaware of the pass-the-hash vulnerability enabled by the mere possession of hashes, without having to brute-force them: http://www.youtube.com/watch?v=DkbBCR_vfRQ http://www.youtube.com/watch?v=DkbBCR_vfRQ (disclaimer: I made this video and was a developer for Metasploit/Nexpose).
  - DanBC 14y ago
    > I don't think this is misinformation. You would be surprised at the number of IT people who have no clue how fast NTLM hashes can be brute-forced. Spreading this knowledge is good. That's just depressing, considering how long this has been a problem. Advice has been, for many years, to avoid using passwords 14 chars or less to force use of NTLMv2. Here's a Microsoft document from 2004: (http://www.windowsecurity.com/articles/Protect-Weak-Authentication-Protocols-Passwords.html http://www.windowsecurity.com/articles/Protect-Weak-Authenti...) > You would be surprised at the number of IT people who have no clue [...] No, you're right. It's widespread lack of knowledge, and letting people know that some stuff is not secure, and other stuff is more secure if you have a complex passphrase, is important.
Daniel_Newby 14y ago
> VCL makes load balancing across the cluster – once an arduous task that required months of custom scripting – a trivial matter. Surely this is an embarrassingly parallel problem that practically balances itself?
alexkus 14y ago
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.
- dave1010uk 14y ago
  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.
  - nwh 14y ago
    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.
    - dbaupp 14y ago
      How long ago did you try this?
      - nwh 14y ago
rorrr 14y ago
> 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.
- alexkus 14y ago
  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.
  - raverbashing 14y ago
    There you go 30 chars password don't matter. Sure, it's not low hanging fruit, but it's not troublesome if you're the target Why? Weakness 1: Because it's written down somewhere. Weakness 2..n: weaker links in the chain
    - DanBC 14y ago
      > Weakness 1: Because it's written down somewhere. This should be part of your risk assessment. For most people and most passwords the risk is not someone riffling through your wallet to find the card with your 30 character password. The risk is from criminal gangs hacking a system and downloading a huge database of usernames / password hashes, and then performing an offline attack on those hashes. For most people writing a good password down and keeping the password safely is better than using a weak password.
rb2k_ 14y ago
Seeing as what kind of GPU farms people ran/run for mining Bitcoin, this is somewhat "in the middle" rather than being a "monster"
- mrb 14y ago
  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!)
nakedrobot2 14y ago
I haven't seen the discussion that I think is really necessary - when are we going to move beyond passwords, which are obviously growing more and more obsolete? What are we going to use instead of passwords in the future?
- ars 14y ago
  There are 3 types: What you know. What you have. What you are. And of the 3 What you know (i.e. password) is the most secure when used properly. It's impossible to steal without your knowledge, and it's impossible to misplace. What you have (eg. physical key) can be stolen from you - or even borrowed, used, and returned without you ever knowing. It can also be copied, and it can be lost - sometimes without being aware of it for a long time. What you are (eg. fingerprint, iris) is the worst, and the least secure. It's trivial to copy - even from a distance, and it's impossible to change. The entropy available is also low. So in the future we are still going to use passwords.
  - Karunamon 14y ago
    What you are.. trivial to copy - even from a distance.. A retinal print?
    - ars 14y ago
      Very easy - just use a telescope.
iuguy 14y ago
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 have what I call seed words (e.g. the password reset word or common words used throughout the organisation) and the majority of passwords are variants of them. My own ability to crack passwords for most algorithms (within a reasonable timeframe) tends to cap at dictionary words with number and letter substitution and somewhere around the 8-10 character mark. Using a phrase means that as an attacker you have to account for other people using more complex but shorter passwords. I'd still suggest getting capitalisation, punctuation or at least a number in your phrase but the bulk of the keyspace comes from the length rather than complexity plus the fact that the people carrying out these attacks are normally cracking more than one password at a time. For a few years now (since around the time of Oeschlin's paper[1]) I've been advising customers to use longer passwords made of phrases and things they can remember for passwords they regularly use[2] and randomly generated passwords of some length stored in a password safe[3] for things they might forget. The goal of this advice is to make it harder for people to crack passwords and to reduce the volume of passwords people have to remember. [1] - http://lasec.epfl.ch/pub/lasec/doc/oech03.pdf http://lasec.epfl.ch/pub/lasec/doc/oech03.pdf [2] - http://xkcd.com/936/ http://xkcd.com/936/ [3] - http://keepass.info/ http://keepass.info/ - one of many options available
- sspiff 14y ago
  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.
  - _ikke_ 14y ago
    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.
RenierZA 14y ago
Can someone please explain why GPUs are so much better at brute force than CPUs? Do they have better instructions/pipelines for the math needed? Why are these not useful/implemented in general CPUs?
- Fixnum 14y ago
  Roughly speaking, CPUs are highly optimized for sequential execution, with long pipelines, high power consumption, and complex implementations of arithmetic/logic instructions (I'm not an expert, but I _believe_ these are much _better_ than on GPUs, except possibly for certain graphics-related GPU primitives), but relatively few threads. GPUs are optimized for parallel execution, and run many more threads than CPUs, each with higher latency, but nonetheless with higher overall throughput.
skriticos2 14y ago
Cute. Following Bitcoin hash generation process, this looks like a toy. FPGA and ASIC hashing would be news on par with contemporary hash generation on smaller scale. This is just a better room heater. (i.e. hashing/W ratio is bad).
- himlion 14y ago
  On the other hand hashing/$ invested is pretty good compared to fpga. I don't think there are any vanilla SHA asics on a modern production process.
ck2 14y ago
Also makes me think we should be using AES256 at a minimum with SSL and not AES128 anymore. With AESNI acceleration available on most servers, there is little penalty to upgrade. They say AES128 is safe until about 2030 but who knows if that took into account super-GPU clusters. (insert imagine a Beowulf cluster of these... comment here)
pkorzeniewski 14y ago
Recently I was thinking about alternative ways of implementing authorization security and I had, maybe a silly, idea - wouldn't it be more secure to always log user in and when given a wrong password, "simulate" (generate) account data? In my opinion it would be much harder to write an algorithm detecting if account data is real or not, and isn't the point of cracking to get access to user data?
shocks 14y ago
I wonder how much heat this this generates? How does it stay cool? I have two GTX 670s in SLI and they can get to about 60 degrees with a gap between them... This many cards sandwiched so close must get really really hot. I don't see any water cooling...
lallysingh 14y ago
Can I rent something equivalent from Amazon by the hour? I wonder how much that would cost.
- mrb 14y ago
  No. Amazon only has Nvidia hardware in their EC2 GPU clusters. Nvidia is not equivalent as it is significantly slower than AMD/ATI hardware for password cracking. Eg. a top-of-the line AMD GPU brute-forces MD5 hashes about 5x faster than a top-of-the-line Nvidia GPU, see: http://golubev.com/gpuest.htm http://golubev.com/gpuest.htm I don't know any computing provider who rent out AMD GPUs... (This would be a startup opportunity.)
dj_sa 14y ago
My password is 24 chracters long, and fully random. I don't memorise it. I use Aladdin to type it for me. http://igg.me/aladdin-key http://igg.me/aladdin-key Aladdin is trying to improve the current situation of people using simple or identical passwords everywhere by removing the need to memorise passwords. Aladdin works with Windows, Mac, Linux as well as Android and iPad. Aladdin is a USB key(board). No software needed.

111 points by _ikke_ 14y ago

Exciting to see the technology behind this field progressing so quickly but troubling considering the passwords my users likely use. Though to be completely realistic their password hashes are very likely already known.

Sam_Odio 14y ago

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 https://hashcat.net/p12/js-sha1exp_169.pdf 2. http://stackoverflow.com/a/4948393 http://stackoverflow.com/a/4948393

_ikke_ 14y ago
Passwords shouldn't be encrypted anyway. Chances are hackers will be able to obtain the key too, and then passwords are really easy to fetch. Passwords should be hashed non-reversible (ideally using a slow hash). The original password is to no use of the application. And sending plain-text passwords to users is even more bad[1]. [1]: http://plaintextoffenders.com/ http://plaintextoffenders.com/
archgoon 14y ago
>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.

akulbe 14y ago

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

mileswu 14y ago
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.html http://help.agilebits.com/1Password3/agile_keychain_design.h...
- xorgar831 14y ago
  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.
  - dfc 14y ago
    "The problem with INSERT-SOMETHING however is that if you pick a weak password it's useless" When is this not the case?
    - schlomie28 14y ago
      When you have a key as well.
  - DanBC 14y ago
    > It would be better if they included an option for a key as well like other password safes do. I would love to see research about the use of keys and passphrases. Especially, do people who have a key then chose a weaker master password?
nwh 14y ago
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.

mileswu 14y ago

“I was extremely disappointed that setting up a clustered VMware instance wouldn’t allow me to create a VM that spanned all the hosts in the cluster. E.g. if i had five VMware ESX hosts with 8 processor cores, I wanted to be able to create a single vm with 40 cores and use all nodes in the cluster,” he wrote. Not sure why he would have thought this would be possible. This would be an extremely hard problem given the latency involved between different nodes. Then he came across VCL, or Virtual Open Cluster... “It did just what I wanted, not with an entire OS per se, but with an entire OpenCL application. and that’s good enough for me.” A similar (but far older) system is MPI[1], which enables parallel computation across many compute nodes for your code by providing message passing. It's kind of a pain to use in my limited experience since you have to adapt your code (it seems like VCL is transparent for OpenCL programs), but it does work. No need for OpenCL, tho of course you could always use OpenCL + MPI. A common thing I see is MPI+OpenMP (for parallel cpu computation). [1] https://en.wikipedia.org/wiki/Message_Passing_Interface https://en.wikipedia.org/wiki/Message_Passing_Interface

peteretep 14y ago

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.wolframalpha.com/input/?i=%2865**16+%2F+63+billion%29+seconds http://www.wolframalpha.com/input/?i=%2865**16+%2F+63+billio...

ErrantX 14y ago
Absolutely; NTLM has been attackable for ages. Running on a Quad core machine it can be cracked in a reasonable amount of time. The cost/time trade-off for such cracking makes this rig pointless for such cracking, unless you absolutely must have it in 6 minutes. I don't see any other major use for this; it's simply not powerful enough to attack anything new (Edit: even with 128, rather than 25, GPU's).
mrb 14y ago
I don't think this is misinformation. You would be surprised at the number of IT people who have no clue how fast NTLM hashes can be brute-forced. Spreading this knowledge is good. Ranting about NTLM, I am also shocked at how many people are unaware of the pass-the-hash vulnerability enabled by the mere possession of hashes, without having to brute-force them: http://www.youtube.com/watch?v=DkbBCR_vfRQ http://www.youtube.com/watch?v=DkbBCR_vfRQ (disclaimer: I made this video and was a developer for Metasploit/Nexpose).
- DanBC 14y ago
  > I don't think this is misinformation. You would be surprised at the number of IT people who have no clue how fast NTLM hashes can be brute-forced. Spreading this knowledge is good. That's just depressing, considering how long this has been a problem. Advice has been, for many years, to avoid using passwords 14 chars or less to force use of NTLMv2. Here's a Microsoft document from 2004: (http://www.windowsecurity.com/articles/Protect-Weak-Authentication-Protocols-Passwords.html http://www.windowsecurity.com/articles/Protect-Weak-Authenti...) > You would be surprised at the number of IT people who have no clue [...] No, you're right. It's widespread lack of knowledge, and letting people know that some stuff is not secure, and other stuff is more secure if you have a complex passphrase, is important.

Daniel_Newby 14y ago

> VCL makes load balancing across the cluster – once an arduous task that required months of custom scripting – a trivial matter. Surely this is an embarrassingly parallel problem that practically balances itself?

alexkus 14y ago

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.

dave1010uk 14y ago
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.
- nwh 14y ago
  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.
  - dbaupp 14y ago
    How long ago did you try this?
    - nwh 14y ago

rorrr 14y ago

> 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.

alexkus 14y ago
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.
- raverbashing 14y ago
  There you go 30 chars password don't matter. Sure, it's not low hanging fruit, but it's not troublesome if you're the target Why? Weakness 1: Because it's written down somewhere. Weakness 2..n: weaker links in the chain
  - DanBC 14y ago
    > Weakness 1: Because it's written down somewhere. This should be part of your risk assessment. For most people and most passwords the risk is not someone riffling through your wallet to find the card with your 30 character password. The risk is from criminal gangs hacking a system and downloading a huge database of usernames / password hashes, and then performing an offline attack on those hashes. For most people writing a good password down and keeping the password safely is better than using a weak password.

rb2k_ 14y ago

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

mrb 14y ago
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!)

nakedrobot2 14y ago

I haven't seen the discussion that I think is really necessary - when are we going to move beyond passwords, which are obviously growing more and more obsolete? What are we going to use instead of passwords in the future?

ars 14y ago
There are 3 types: What you know. What you have. What you are. And of the 3 What you know (i.e. password) is the most secure when used properly. It's impossible to steal without your knowledge, and it's impossible to misplace. What you have (eg. physical key) can be stolen from you - or even borrowed, used, and returned without you ever knowing. It can also be copied, and it can be lost - sometimes without being aware of it for a long time. What you are (eg. fingerprint, iris) is the worst, and the least secure. It's trivial to copy - even from a distance, and it's impossible to change. The entropy available is also low. So in the future we are still going to use passwords.
- Karunamon 14y ago
  What you are.. trivial to copy - even from a distance.. A retinal print?
  - ars 14y ago
    Very easy - just use a telescope.

iuguy 14y ago

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 have what I call seed words (e.g. the password reset word or common words used throughout the organisation) and the majority of passwords are variants of them. My own ability to crack passwords for most algorithms (within a reasonable timeframe) tends to cap at dictionary words with number and letter substitution and somewhere around the 8-10 character mark. Using a phrase means that as an attacker you have to account for other people using more complex but shorter passwords. I'd still suggest getting capitalisation, punctuation or at least a number in your phrase but the bulk of the keyspace comes from the length rather than complexity plus the fact that the people carrying out these attacks are normally cracking more than one password at a time. For a few years now (since around the time of Oeschlin's paper[1]) I've been advising customers to use longer passwords made of phrases and things they can remember for passwords they regularly use[2] and randomly generated passwords of some length stored in a password safe[3] for things they might forget. The goal of this advice is to make it harder for people to crack passwords and to reduce the volume of passwords people have to remember. [1] - http://lasec.epfl.ch/pub/lasec/doc/oech03.pdf http://lasec.epfl.ch/pub/lasec/doc/oech03.pdf [2] - http://xkcd.com/936/ http://xkcd.com/936/ [3] - http://keepass.info/ http://keepass.info/ - one of many options available

sspiff 14y ago
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.
- _ikke_ 14y ago
  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.

RenierZA 14y ago

Can someone please explain why GPUs are so much better at brute force than CPUs? Do they have better instructions/pipelines for the math needed? Why are these not useful/implemented in general CPUs?

Fixnum 14y ago
Roughly speaking, CPUs are highly optimized for sequential execution, with long pipelines, high power consumption, and complex implementations of arithmetic/logic instructions (I'm not an expert, but I _believe_ these are much _better_ than on GPUs, except possibly for certain graphics-related GPU primitives), but relatively few threads. GPUs are optimized for parallel execution, and run many more threads than CPUs, each with higher latency, but nonetheless with higher overall throughput.

skriticos2 14y ago

Cute. Following Bitcoin hash generation process, this looks like a toy. FPGA and ASIC hashing would be news on par with contemporary hash generation on smaller scale. This is just a better room heater. (i.e. hashing/W ratio is bad).

himlion 14y ago
On the other hand hashing/$ invested is pretty good compared to fpga. I don't think there are any vanilla SHA asics on a modern production process.

ck2 14y ago

Also makes me think we should be using AES256 at a minimum with SSL and not AES128 anymore. With AESNI acceleration available on most servers, there is little penalty to upgrade. They say AES128 is safe until about 2030 but who knows if that took into account super-GPU clusters. (insert imagine a Beowulf cluster of these... comment here)

pkorzeniewski 14y ago

Recently I was thinking about alternative ways of implementing authorization security and I had, maybe a silly, idea - wouldn't it be more secure to always log user in and when given a wrong password, "simulate" (generate) account data? In my opinion it would be much harder to write an algorithm detecting if account data is real or not, and isn't the point of cracking to get access to user data?

shocks 14y ago

I wonder how much heat this this generates? How does it stay cool? I have two GTX 670s in SLI and they can get to about 60 degrees with a gap between them... This many cards sandwiched so close must get really really hot. I don't see any water cooling...

lallysingh 14y ago

Can I rent something equivalent from Amazon by the hour? I wonder how much that would cost.

mrb 14y ago
No. Amazon only has Nvidia hardware in their EC2 GPU clusters. Nvidia is not equivalent as it is significantly slower than AMD/ATI hardware for password cracking. Eg. a top-of-the line AMD GPU brute-forces MD5 hashes about 5x faster than a top-of-the-line Nvidia GPU, see: http://golubev.com/gpuest.htm http://golubev.com/gpuest.htm I don't know any computing provider who rent out AMD GPUs... (This would be a startup opportunity.)

dj_sa 14y ago

My password is 24 chracters long, and fully random. I don't memorise it. I use Aladdin to type it for me. http://igg.me/aladdin-key http://igg.me/aladdin-key Aladdin is trying to improve the current situation of people using simple or identical passwords everywhere by removing the need to memorise passwords. Aladdin works with Windows, Mac, Linux as well as Android and iPad. Aladdin is a USB key(board). No software needed.