GPU Processing and Password Cracking

Recently, research students at Georgia Tech released a report outlining the dangers that GPUs pose to the current state of password security. There are a number of ways to crack a password, all with their different pros and cons, but when it comes down to it, the limiting factor in all of these methods is processing complexity. The more operations that need to be run, the longer it takes, and the less useful each tool is for cracking passwords. In the past, most recommendations for password security revolved around making sure your password wasn’t something predictable, such as “password” or your birthday. With today’s (and tomorrows) GPUs, this may no longer be enough.

Although the article never mentions them by name, the newest tools in password cracking are based around two tools, nVidia’s CUDA and AMD’s Stream SDKs. These tools allow programs to be written in C that can be broken up and utilize the parallel nature of the hardware that is usually optimized for graphics. GPUs are much better at large-scale mathematical operations than CPUs because of this parallel layout. Chances are, if you have a somewhat recent graphics card, it is probably compatible with either CUDA or Stream, and if you already know C, you have all the tools necessary to get started.

The lesson to learn here, the longer or more complex a password is, generally the safer it is. Because of this, a number of tools, both software and hardware, may become more and more popular, or necessary, to accommodate this need.

Yes, I’m reviving a long-dead comment thread. Still.
I believe you misunderstand the purpose of GPU hash-cracking. In order to crack a password via this method, you need to already have the hash of the password that is stored in the system in question. The brute-force part comes when you un-hash the password: un-hashing takes a LOT of power.

i have dual nvidia GTX 480s in sli in my desktop and it makes rendering and film processing a breeze so password cracking would be simple no?
i mean brute force attacking and hash cracking is nothing more than a bunch of small not so complex tasks and with over 900 cores per GPU than it should speed things up right?

WPA cracking is a poor example. You still have to “listen to the data sent over the WLAN for a few hours,” so cracking gramma’s wifi password isn’t the bottleneck, the acquisition of data remains the hurdle.

As long as people pick good passwords that aren’t going to be on a wordlist, things are pretty secure. A plain old bruteforce attack will still take a very long time.

I sometimes think about the fact that, given enough time, all these encryptions will be a computational breeze to bruteforce. I could just sniff your encrypted data, wait 10 – 15 years, and get your secret then. It usually doesn’t matter, since your secret probably won’t be very important after 10 years. I do, however, imagine it should matter to governments and people who like to send files called, “encrypted_pics_of_my_gf.rar”.

People who use encryption for government-type secrets or even just people who know what they are talking about (though I do not claim to be one of them) design cryptography algorithms (hashes, symmetric and asymmetric cryptography, etc.) so that not only the computational power for current computers is far to weak, but they also look into what could be possible in the future.

Given a pure brute force attack and no further breakthrough in CS/mathematics (no attacks in the algorithm allowing to select a subset of possible plaintexts without actually testing them for example), there is such a thing as a “big enough key” for a given algorithm, so that the computational power of silicon CPU will NEVER reach a point at which it can brute force it in reasonable time, no matter how big and fast you make it.
This kind of calculation is generally not done vs. the latest i7, GTXblabla, …, but more in terms of total energy and time needed compared to “big values”, in the order of the age of the universe. So, like I said, without breakthroughs and research, you can’t just throw computational power at brute force and hope it will solve itself…

For those who are interested, I’d recommend a book like Bruce Schneier’s Applied Cryptography, which has everything from the basic concepts to the theory and implementation, though I’m sure the same information can be found on the net somewhere.

@lolzertank yeah, it is easy for encryption to out pace technology, BUT as someone else already pointed out, that only works with current encryption technology — if I sniff your data now, and crack it in 10 or 20 years on my cell phone, I still have it cracked — though — as was also already said, it’s probably not going to be worth anything in that time.

The ability and relative ease of using GPUs for encryption breaking has been known and used far longer than two years ago.
It’s the reason why the US gov’t get’s all flustered when a connex container full of playstatons and video ipods are shipped to certain countries that don’t like us.
The developement was on the software side of things with the release to the public of SDKs that lower the implementaion hurdle considerably.

I hope people start releasing programs that take advantage of the power of GPUs. Even those not aimed at encryption breaking would benefit.

There is a hidden point that’s being missed here.
It’s true, superfluous characters added to a password can make it quite more difficult to brute force, and an arbitrarily long password can possibly make a brute force attempt futile, BUT —

if an arbitrarily long password is changed at an arbitrarily small interval, any brute force attempt, no matter how fast (up to a certain, currently unachievable point) will be rendered useless, even if it provides the correct secret.

In practical application, if you have a system that generates a 256-bit password at random, at least 1024 times per second, and requires a perfectly synchronized password to gain access to an otherwise implausibly secure computer system, any brute force attack would be mostly useless.

My understanding is that brute force password cracking operations is highly scalable. A naive approach is working on the same cyphertext in parallel with different key ranges across several compute domains.

And why do you think matrix operations can not be parallelised? They can be split up into several compute domains in various ways. There is several decades worth of research in this area.

Things have never been so sweet now that OpenCL and CUDA is becoming more popular.

2. Don’t allow access to the password database file in the first place, once again no brute forcing.

There is no concern for passwords being brute forced online if all the two steps above are done. There is also no concern of said rainbow tables on windows passwords if the said password data base file can’t be accessed. This stuff is a no brainer. Passwords will always be safe with these systems.

@deathshadow
“… and if you are sending ANYTHING that gives access to the passwords database you’re a retard!”
Yeah, if you have a single vulnerability in your website, you’re retarded! How could you not notice that one of the many apps your company runs or hosts has a vulnerability in it?

I work for an asset management company interning for web application security, and we have A LOT of applications. It only takes one of them to have a vulnerability to allow people to start mining database information, possibly including hashed passwords. At that point, they don’t really them, but they can get a user’s name, email, all other kinds of information. With that, and if they assume the user uses the same or a similar password for their accounts, they can start really damaging individuals.

You can get a WPA/WPA2 hash in about 5 min or less. Use airepley to deauth the client, when they reconnect you get the hash. It takes maybe a minute.

The people who really should be shaking in their boots are the people that use the default passwords on ATT’s 2WIRE modems as they have a 10 digit password. Without GPU cracking it would take forever to crack, with GPU cracking (pyrit) crunch to generate the numbers (so you dont need a huge password file) you can be done in a couple days.

In any decently written web application, even with a full copy of the database brute forcing just is not an option without also having file access, which usually means physical access, and at that point all is lost anyways. I’ve been writing a CMS for personal use, with my salting and hashing routine each password has around 100 trillion permutations per password before you even get to try breaking the hash, and thats if you’ve happened to grab the salt lists without them it’s around (turns out I can’t tell you, my online permutation calculator responds with “INFINITY”) I doubt that without physical access the password “cat” could be brute forced, add to that that each site has there own different method of salting, and getting a job at the web host seams like the easy way.

well, on a more positive side of this, we’ll probably be seeing some games that take advantage of extra GPUs pretty soon. even if not, just pop in another GPU, write a driver that registers it to windows/linux/mac as an extra CPU, then there you go, high speed games!

I think we are all overlooking the implications this has in regard to cyberwarfare. According to my calculations, the Quadro 6000, nVidia’s top of the line simulation and hardcore 3D rendering solution, has an effective speed approaching 500GHz.

Considering elcomsoft was doing this back in 2007 and continue to apply it to new GPUs and encryption processes it is old news. They wrote a paper to increase awareness of this “vulnerability” for people who have had their head buried in the sand for the past 3 years. If waving your hands and shouting about something that happens is the best you can do as a research scientist we are screwed, but I already had the figured when the picture showed three white guys instead of an asian.