Slashdot Mirror


Brute-Force Password Cracking With GPUs

An anonymous reader writes "We all know that brute-force attacks with a CPU are slow, but GPUs are another story. Tom's Hardware has an interesting article up on WinZip and WinRAR encryption strength, where they attempt to crack passwords with Nvidia and AMD graphic cards. Some of their results are really fast — in the billions of passwords per second — and that's only with two GTX 570s!"

18 of 128 comments (clear)

  1. I wonder by NoNonAlphaCharsHere · · Score: 5, Funny

    If we throw enough GPUs at it, if we could detect dupes on Slashdot?

  2. old news by Anonymous Coward · · Score: 2, Insightful

    this has been known since 2009....

  3. This is why you use encryption programs... by mlts · · Score: 3, Interesting

    WinZIP and WinRAR have effective encryption, but one needs to have an effective passphrase with it.

    Ideally, the best way to encrypt stuff is with not just a passphrase, either with random keyfile for symmetric encryption, or use public key crypto (although PK crypto has its own caveats). This way, there is no brute-forcable passphrase to guess, so an attacker has to deal with the complete keyspace of an encryption algorithm, and not just what people type in.

    1. Re:This is why you use encryption programs... by pathological+liar · · Score: 2

      Typically bruteforcing refers to exhaustively searching a reduced dictionary... bruteforcing 62^8 (alphanumeric, mixed case, a reasonable metric for a 'decent' password) might be easier with a GPU investment, bruteforcing 256^32 (let's assume a 256bit keyspace) is not.

    2. Re:This is why you use encryption programs... by Jahava · · Score: 5, Informative

      I was under the impression that brute forcing did exactly that. They're not using a dictionary. They're taking advantage of the GPU processing power.

      For this kind of encryption, the archive password is converted into a key. This is done because remembering a large key is hard, but remembering a password is not.

      However, this kind of conversion is not remotely secure. With around 70 typable characters ("a-z", "A-Z", "0-9", a few symbols, etc.) the number of possible keys for keylength l is around 70^l . If we use a secure crypto algorithm, say, AES-256, then we would encrypt the archive with a 256-bit key. Something that uses a password for encryption does so by permuting the password into a key, typically through some combination of hashing, concatenation, and salting. This process deterministically maps the relatively-small ASCII password space to a 256-bit key space. So even though you're using a secure-sized 256-bit key, there are still only (at most) 70^l possible keys, since each key must be generated from a password.

      Now, with AES-256, there are 2^256 possible keys. While brute-forcing the 256-bit keyspace is considered hard (that works out to about 1 * 10^77 possible keys), brute-forcing the possible plaintext passwords that could have generated the key is significantly easier (a 10-character password has only 2 * 10^18 possibilities).

      So back to what the OP said, while the crypto and keysize of the underlying cryptography are secure (in this example, AES-256), the keyspace is inherently limited since it has to be derived from a much-smaller set of passwords. The OP is spot-on ... if you really want to encrypt something securely, you have to use a much larger keyspace, which, in this case, means generating a complete 256-bit key rather than deriving one from an ASCII password. This article shows that password-derived keys are not secure.

    3. Re:This is why you use encryption programs... by Jahava · · Score: 2

      I don't know where your delusion of 70 "typable" keys comes from. Maybe from being egocentric, and thinking ASCII-only. PROTIP: http://www.neo-layout.org/

      Good luck scanning through way more Unicode key combinations

      Also: what stops a hacker from trying out passwords on the keyfile instead of the encrypted file?

      It's an example to demonstrate how much more limited the typable keyspace is than an unconstrained binary keyspace, nothing more. I think you're quite out of line throwing words like "egocentric" around because an arbitrary example used QWERTY/ASCII.

      However, say you did have 1024 typable characters. A random 10-character password with such a keyboard layout would yield only about (at most) 1024 ^ 10 = possible combinations, still well short of the example binary keyspace.

      We're getting a bit off-topic, but if anyone's interested, more information on a method of deriving keys from passwords can be found here. Notice how part of the process cycles over and over again to increase the computing time required to exhaust the keyspace. If you cycle 10,000 times, the decryptor only has to perform 10,000 operations, but a brute-force technique has to perform 10,000 operations for every password attempt, greatly increasing the CPU time required for each attempt. This is an attempt to compensate for the different in keyspace sizes by increasing CPU time outside of the cryptographic algorithm.

    4. Re:This is why you use encryption programs... by Anonymous Coward · · Score: 2, Informative

      I find it strange that you discount using a longer passphrase without bothering to calculate how long it would need to be. Assuming 70 typeable characters, getting 2^256 possible keys only requires 256*ln(2)/ln(70) ~ 42 characters assuming an equal distribution. (english text actually has much less entropy than an ideal even distribution of characters, but we'll ignore that for the time being)

      As an example, "This is a fourty two character passphrase!" is a fourty two character passphrase. It's not unreasonable to blind-type something like that into a password field for someone with a reasonable amount of typing skill.

      The main trouble is that people get the idea that passwords should be as compact as possible. This is partially due to using the term "password" instead of "passphrase", and partly due to stupid, stupid systems which impose a maximum length limit on passwords.

  4. Re:Umm... by amicusNYCL · · Score: 3, Informative

    Even though it's a dupe, why are GPUs so much faster than CPUs at this? It doesn't seem like they have any more power, is the architecture that different from CPUs? Is it an issue where you can basically dedicate all resources (GPUs plus VRAM) to the one task?

    --
    "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
  5. Re:Umm... by adonoman · · Score: 5, Informative

    CPUs and GPUs have very different focuses. A CPU is designed to take a single piece of data, run an operation on it, then grab a different piece of data, and run another operation on it. (There's a whole bunch of optimizations for running the same operation on different bits of data, and different operations on the same bit of data, but those are largely optimizations, and only apply to relatively small scales). A GPU is designed to take a butt-load (technical term) of data, and perform the same operation on all that data, followed by another operation on that same butt-load of data.

    When you are cracking passwords, you have a bunch of potential passwords you want to try. On a CPU, you are stuck with hashing between 1 and maybe a dozen simultaneously. On a GPU, you could potentially run a few million simultaneously. Each step on the GPU would be slower, but your total output of hashed passwords would be much higher.

  6. Why none of this matters! by SirAstral · · Score: 2

    For most intents and purposes this is not that news worthy. In order to get processing performance like this you need a system that can also answer billions of password guesses per second. So keeping it simple, you need to get said database, make it function on/in a system/environment that can handle and that will allow this much activity for all those guesses.

    ergo, someone has to jack yo shit before they can start guessing your password which may be more difficult than just trying to guess that password leaving you back to square one where you will most likely do something OTHER than a brute force/dictionary password attack!

  7. Re:Umm... by Anonymous Coward · · Score: 2, Insightful

    Does anyone remember when you could come on this website and have a discussion on this website and learn about new concepts and ideas? Don't be so bitter, even you were a noob at some point in your life.

  8. Re:Umm... by Anonymous Coward · · Score: 3, Informative

    GPUs are much more specialized than CPUs. CPUs can only do a few things in parallel depending on the number of cores available in the CPU chip (ie 4). GPUs have a magnitude more processing paths than CPUs, the GTX 570 mentioned has 480 cores. That's what's being leveraged here, it's not the resources or power, it's the number of parallel processing paths.

  9. Re:Umm... by wintertargeter · · Score: 2

    No. Zdnet used ighashgpu. That's a hash cracker. WinZip and WinRAR encyption is different because it's based on precomputed password hashes. It looks like TH used AccentZip and AccentWinRAR to decrypt passwords.All three programs are created by Ivan Golubev. His blog is full of posts on cryptography performance.

  10. Re:Why are GPUs faster? by JamesP · · Score: 2, Informative

    In layman terms: The CPU is like a truck, the GPU like a Ferrari

    One goes faster, but can't run on all kinds of terrain (data)

    --
    how long until /. fixes commenting on Chrome?
  11. Re:Why are GPUs faster? by 140Mandak262Jamuna · · Score: 2
    GPUs are not really that much faster. GPUs are essentially tiny CPUs with very limited, I mean extremely limited cache/register/instruction sets. And they throw in hundreds or even thousands of these together in a card. Essentially GPUs are large number of weak processors. Some problems are "embarrassingly parallel", painting a 3D scene on a 2D screen or testing a guess passwords of an encrypted file. Some other problems are quite parallel but you need to aggregate the data at the end, like multiplying a matrix by a vector. Some problems are very difficult to parallelize. Decomposing a mesh/grid of a 3D domain into million small tetrahedrons and hexahedrons is extremely difficult to parallelize.

    It just so happens, guessing a password can be done by a relatively weak CPU and one can pack thousands of such weak CPUs in one card and buy it cheaply. That is all. Don't hold your breath waiting for GPU to solve the Navier-Stokes equation for the Large Eddy simulation with particle combustion anytime soon.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
  12. Password length matters by pugugly · · Score: 3, Informative

    Things to remember - password difficulty is based on x^y, where x is the number of possible characters and y is the password length. Increasing password length is *always* going to be more effective than increasing the mix of characters (indeed the point of a dictionary attack is to reduce can be thought of as reducing 96^8 8 character passwords to a mere 250,000^1).

    Each additional alphanumeric character increases the search space by a factor of 62 - a two word password is still only 250,000^2, a password of ten random lowercase characters is 26^10, a *much* larger number.

    Moores law says processing power doubles ~18 months. Every new lowercase character extends life of your password almost 12 years before new hardware can decrypt it as quickly as today's hardware. 23 1/2 if you use upper and lowercase.

    Don't panic.

    --
    An Invisible Entity of Vast Power whose existence must be taken on faith alone: Liberal Media
  13. Re:Why are GPUs faster? by TerranFury · · Score: 5, Insightful

    More like, a GPU is a freight train moving at 15 MPH, a CPU is a Ferarri doing 120MPH, and you need to transport a warehouse of boxes across country.

  14. Re:Umm... by petit_robert · · Score: 2

    >Been around since ~1997 too. Perhaps technical discussions went on here some time before that?

    I have read comments to the same effect in other discussions (can't find one at the moment).

    I'll admit I noticed a sort of dilution of the technical level of late, but it may be the price to pay for popularity. I followed some very interesting discussions here, and recently.

    Besides, who could follow high level technical discussions about so many subjects? For instance, the posts below yours, that quickly explain why GPUs are good at password cracking, are _good_ information for me.