The numbers are ... misleading ... and choosing NTLM hashes seems like bordering on misinformation.<p>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:<p>- 10 chars: 35 weeks<p>- 11 chars: 44 years<p>- 12 chars: 2,800 years<p>- 16 chars: 11 times the age of the sun<p>10 chars for bcrypt: 600,000 years...<p><a href="http://www.wolframalpha.com/input/?i=%2865**16+%2F+63+billion%29+seconds" rel="nofollow">http://www.wolframalpha.com/input/?i=%2865**16+%2F+63+billio...</a>
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.<p>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.<p>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.<p>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.<p>[1] - <a href="http://lasec.epfl.ch/pub/lasec/doc/oech03.pdf" rel="nofollow">http://lasec.epfl.ch/pub/lasec/doc/oech03.pdf</a><p>[2] - <a href="http://xkcd.com/936/" rel="nofollow">http://xkcd.com/936/</a><p>[3] - <a href="http://keepass.info/" rel="nofollow">http://keepass.info/</a> - one of many options available
<i>“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.</i><p>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.<p><i>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.”</i><p>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).<p>[1] <a href="https://en.wikipedia.org/wiki/Message_Passing_Interface" rel="nofollow">https://en.wikipedia.org/wiki/Message_Passing_Interface</a>
For an embarrassingly parallel task like this why does there need to be any blazingly fast communication between the nodes at all?<p>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.<p>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!<p>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.
It looks like - contrary to the article - the presenters are discussing hash functions, not encryption[1]. There is a difference[2].<p>That said, I'd be curious to know how long it'd take a device like this to decrypt "secure" AES256 text.<p>1. <a href="https://hashcat.net/p12/js-sha1exp_169.pdf" rel="nofollow">https://hashcat.net/p12/js-sha1exp_169.pdf</a><p>2. <a href="http://stackoverflow.com/a/4948393" rel="nofollow">http://stackoverflow.com/a/4948393</a>
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?
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?
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.
My password is 24 chracters long, and fully random. I don't memorise it. I use Aladdin to type it for me. <a href="http://igg.me/aladdin-key" rel="nofollow">http://igg.me/aladdin-key</a><p>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.<p>Aladdin is a USB key(board). No software needed.
Also makes me think we should be using AES256 at a minimum with SSL and not AES128 anymore.<p>With AESNI acceleration available on most servers, there is little penalty to upgrade.<p>They say AES128 is safe until about 2030 but who knows if that took into account super-GPU clusters.<p>(insert <i>imagine a Beowulf cluster of these...</i> comment here)
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...
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).
Can someone please explain why GPUs are so much better at brute force than CPUs?<p>Do they have better instructions/pipelines for the math needed? Why are these not useful/implemented in general CPUs?
> <i>That renders even the most secure password vulnerable to compute-intensive brute force</i><p>No it doesn't. My passwords are 30-character randomly generated and look like this:<p><pre><code> T7PN2m7Yju43IWtoBkwL6TLx18Rdyq
</code></pre>
Do you want to guess how long it will take to bruteforce with that "monster"?<p><pre><code> (26 + 26 + 10)^30 = 5.91 × 10^53 possible combinations
</code></pre>
At 348 billion guesses per second it will take<p><pre><code> 1.53 × 10^42 seconds
</code></pre>
or<p><pre><code> 4.84 × 10^34 years
</code></pre>
That's quite a bit longer than the age of the universe.
> VCL makes load balancing across the cluster – once an arduous task that required months of custom scripting – a trivial matter.<p>Surely this is an embarrassingly parallel problem that practically balances itself?