
New 25 GPU Monster Devours Passwords In Seconds - _ikke_
http://securityledger.com/new-25-gpu-monster-devours-passwords-in-seconds/
======
peteretep
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+billio...](http://www.wolframalpha.com/input/?i=%2865**16+%2F+63+billion%29+seconds)

~~~
Keyframe
I'm kind of rusty on algorithmic information theory (I'm an artist, heh)! Is
there such a thing as (formalized) upper limit of what we could do as far as
computing combinations go? I know of Kolmogorov complexity (vaguely), but what
are the hard limits and challenges of just prodding through (faster and faster
as tech goes forward) combinations until success? I plan on developing a story
around that and make a movie out of it - so any help would be appreciated (you
guys can contact me via email if you want).

~~~
itry
"what are the hard limits and challenges of just prodding through (faster and
faster as tech goes forward) combinations until success?"

According to current theory of physics, every computation needs at least a
certain amount of energy. So if you want to do many computations today, you
will have to use a certain amount of energy today. Now lets say, you have a
machine that turns any matter into energy without any loss. You put in m mass
and you get out e=mc^2 energy. Problem is: You cannot get more matter into
that machine today then is around you in a radius of 24 light hours.

So that would be a hard limit.

But quantum computers have proven to break that limit. One theory is that
using a quantum computer means using computers in an unlimited number of
parallel universes. So there is no limit to the number of calculations you can
do. (See David Deutsch and his theories about parallel universes)

I think there are theories about the limits of what a quantum computer can
calculate. But I dont know them. Would be interesting to read about it if
there is something published.

Then again, what might look like a "hard limit" today will probably not do so
tomorrow. Some time ago the "lower limit on energy per calculation" sounded
like a hard limit. Then quantum computers came along and blasted through it.

~~~
AnIrishDuck
> According to current theory of physics, every computation needs at least a
> certain amount of energy.

This is not, strictly speaking, true. You are talking, I believe, about
Lanadauer's principle [1]. This states that it is the _destruction of entropy_
that costs energy. There are computational methods that can theoretically
avoid these energy losses [2]. In fact, Lanadaer theorized about reversible
computing in his original paper [3].

Bremmerman's limit, mentioned below, is more applicable.

1\. <http://en.wikipedia.org/wiki/Landauer%27s_principle> 2\.
<http://en.wikipedia.org/wiki/Reversible_computing> 3\.
[http://www.cc.gatech.edu/computing/nano/documents/Bennett%20...](http://www.cc.gatech.edu/computing/nano/documents/Bennett%20-%20The%20Thermodynamics%20Of%20Computation.pdf)

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

[2] - <http://xkcd.com/936/>

[3] - <http://keepass.info/> \- one of many options available

~~~
ZoFreX
It's worth pointing out that length is not important, only entropy is
important. If you create a really long phrase by forming a sentence from very
common English words, the entropy is actually really low, and if everyone
started doing this you can bet your boots the password crackers would catch
up.

However you create your password you should take a stab at calculating the
entropy (and incidentally a 10 character truly random password with
alphanumeric+specials will be very hard to crack - it's the fact that the
passwords are mutations of a seed word that makes them weak, and not their
short length)

~~~
vonuebelgarten
> It's worth pointing out that length is not important, only entropy is
> important.

Entropy is important, but multi-word passwords stills being efficient since
their alphabet is quite large when compared with common alpha-symbolic-numeric
passwords.

For example, a completely random password with 12 digits and upper/lower case
letters have (26+26+10)^12 = 3.226e21 possibilities. Quite good __unless __you
need to memorize this thing. I use such nonsense things for password stored in
my password safe.

A password with four very common words (among the 1000 most common words in
the user's native language, which I assume the attacker know) have 1e9
possibilities -- __very __bad. Relevant XKCD for explaining how bizarre is an
English text with such restricted vocabulary:<https://xkcd.com/1133/>

A password with five words selected among the most 4000 words of the user's
native language have 1.024e+18 possibilities. Put some uncommon/random/made-up
word in the mix is enough to make a direct attack on the password non-viable
and force the attacker to search for more elaborated methods. Plus side: is
easy to memorize.

~~~
codex
I should point out that multi-word passwords have at least one disadvantage:
if you can figure out which letters were used and/or the password's length,
and you know the password is multi-word, then it becomes easier to derive what
the password was.

So, for example, if you used a multi-word password on your ATM machine, and
someone aimed an infrared camera at the machine after you left and retrieved
the set of buttons that you pressed, the game would be over if your password
were short--or at least much closer to being over if it were long.

Alternatively, an attacker could eavesdrop on your keyboard sounds and capture
the timing of the clicks, thereby inferring candidate sets of letters. Or they
could examine how much oil is on each key of your keyboard, or how much each
key is worn, and adjust for the stats on the English language, etc.

Or, as in the ATM case, an agent could interrupt you right after you've
entered your password on a false pretext ("Excuse me, I need help.") and
surreptitiously take an in infrared photo of your keyboard. This is plausible
in many semi-public scenarios (bank teller, etc.)

I think the saving grace here is that a sufficiently long password uses most
letters in the English alphabet--but it is still prone to attack if you can at
least get the relative ordering of some of the letters, or you know the
password's length (by listening to the number of keyboard clicks, for
example).

------
mileswu
_“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>

------
alexkus
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
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
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
How long ago did you try this?

~~~
nwh
About a year and a half ago. Long enough that I can't find the source to try
it out in a newer browser.

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

~~~
_ikke_
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/>

------
pkorzeniewski
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?

------
nakedrobot2
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
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
_What you are.. trivial to copy - even from a distance.._

A retinal print?

~~~
ars
Very easy - just use a telescope.

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

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

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.

------
rb2k_
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
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!)

------
ck2
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)

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

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

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

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

~~~
mileswu
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...](http://help.agilebits.com/1Password3/agile_keychain_design.html)

~~~
xorgar831
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
_"The problem with INSERT-SOMETHING however is that if you pick a weak
password it's useless"_

When is this not the case?

~~~
schlomie28
When you have a key as well.

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

~~~
mrb
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>

I don't know any computing provider who rent out AMD GPUs... (This would be a
startup opportunity.)

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

~~~
raverbashing
True

That´s why I use a 'throwaway' password for most unimportant accounts. Sure,
may be easy to break, but it isn't logging in to my gmail.

Don't forget also the risk of getting locked out of your account.

~~~
bigiain
I fell victim to that once, when I hadn't "upgraded" the re-used throwaway
password I'd used to register to see what some random website was. When my
throwaway password got exposed (in cleartext _facepalm!_ ) by PerlMonks,
within a day or so someone had used it to send Acai Berry spam through my
Twitter account (which 'd completely forgotten was still using a
shared/throwaway password even though it had turned from "some random new
website I was curious about" into "somewhere where I actually care about my
online reputation").

Just don't re-used passwords _anywhere_ - choose a password generation/storage
solution that works across all your devices, and use it to generate unique
strong passwords for everything. (1PassWord + DropBox works great for me
across my MacOSX, iOS, Android, and Windows devices - I occasionally would
like it on Linux too, but rarely enough that I'm satisfied to use my phone and
re-type passwords in Linux)

~~~
raverbashing
Interesting. It is certainly needed to "upgrade" passwords sometimes.

My beef with 1PW is that it's a single point of failure, not to mention
inconvenience/risks. For example, what if I need to check gmail in a trusted,
but borrowed device.

The main issue I think is that using only one password for security is
insufficient (but not necessarily go for a 2-factor auth)

~~~
bigiain
On the "inconvenient/risks" point - yeah, security is pretty much always a
trade-off between convenience and risk. I've already chosen two factor auth
for gmail (and Amazon and Dropbox, and I'll add any other important service I
can to that list when available), so I pretty much need access to one of my
two phones or my iPad to run the TOPT token generator - and if I have any of
those devices there's clearly no need to me to trust a borrowed device.

(Though in the complete disaster scenario, I have stored in my wallet, as
suggested by Bruce Schenier, the app-password my phones use and the list of
backup verification codes - unlabelled so a casual thief _probably_ won't know
what to do with them... I've also got irregular exports of everything and the
1Password passphrase and phone PIN printed out and stored in an envelope in
the office safe. I _think_ I'm sufficiently paranoid about all that...)

------
Daniel_Newby
> 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?

