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!"

128 comments

  1. Umm... by taktoa · · Score: 1

    Didn't we hear about this a week or two ago?

    1. Re:Umm... by Jawnn · · Score: 1

      Yes, though not sure it was the Tom's Hardware article. Whatever - that GPU's are fast at brute-force password cracking or... mining BitCoins (There, I said it!), is not exactly news today.

    2. Re:Umm... by lennier1 · · Score: 1

      It's been known for quite some time, but apparently the one who submitted it and the editor who greenlit it didn't get the memo.

    3. 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
    4. Re:Umm... by jgtg32a · · Score: 1

      GPUs are massively parallel, and doing something straight forward as running a hash a few billion times works much better in parallel than serial.

    5. Re:Umm... by marnues · · Score: 1

      It's the parallelization. The GPU could check a lot more passwords at the same time.

    6. Re:Umm... by toadlife · · Score: 1

      I read somewhere else that GPUs are better at raw number crunching that general purpose CPUs, which makes them more efficient at cracking passwords.

      --
      I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
    7. Re:Umm... by toadlife · · Score: 1

      And based on the replies you've gotten, maybe I read wrong?

      --
      I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
    8. Re:Umm... by Anonymous Coward · · Score: 1, Insightful

      Does anyone else remember the days when slashdot readers were technical? This discussion is fucking painful.

    9. Re:Umm... by realityimpaired · · Score: 1

      Yes, it was the Tom's Hardware article... the link was marked as visited and I generally avoid TH....

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

    11. Re:Umm... by toadlife · · Score: 1

      Does anyone else remember the days when slashdot readers were technical?

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

      --
      I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
    12. Re:Umm... by Sulphur · · Score: 1

      It's been known for quite some time, but apparently the one who submitted it and the editor who greenlit it didn't get the memo.

      Did they crack the memo?

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

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

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

    16. Re:Umm... by Anonymous Coward · · Score: 0

      Second option, no one cares about your posts

    17. Re:Umm... by Anonymous Coward · · Score: 0

      People do say that a lot, but it's really not especially accurate. It's really the parallelization.

    18. Re:Umm... by amicusNYCL · · Score: 1

      Thanks. Would the GPU have a single, multi-stage pipeline (with apparently a lot more stages than a CPU), or does it actually have multple pipelines? Or maybe just a ton of small cores? I'm confused about where the parallelity (technical term) actually gets implemented in the hardware.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    19. Re:Umm... by Man+Eating+Duck · · Score: 1

      And based on the replies you've gotten, maybe I read wrong?

      Depends on what types of number crunching you're doing. If every step depends on the previous step then you won't be able to exploit the hundreds of cores that makes up even a cheap GPU these days by running them in parallel. If, on the other hand, your task consists of subtasks which can be easily done simultaneously like password hashing (just send a separate password to be hashed to all cores at once) or n-body calculations you will experience huge speedups. If you do a lot of matrix (vector) operations the GPU is also very well suited as it contains specialised hardware for such tasks.

      Each GPU unit is also a lot simpler than a general purpose CPU, which means that you may have to implement your algorithms in a less efficient way. So, it depends on the task :)

      --
      Are you a grammar Nazi? I'm trying to improve my English; please correct my errors! :)
    20. 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.

    21. Re:Umm... by Anonymous Coward · · Score: 1

      Recent GPUs have hundreds of relatively simple cores. As you can see here.

    22. Re:Umm... by gman003 · · Score: 1

      It's multiple cores. Usually in the low hundreds, but some have over a thousand - a Radeon HD 6990 has, if my data is correct, 3072 cores running at 830mHz, combined with 4GB of memory optimized for parallel access. Although to be fair, it does so with about triple the power consumption of a high-end desktop processor. So compare it to, say, three i7 CPUs - you'd get 18 cores (that act like 36 because of SMT), clocked at 3466mHz.

      Of course, a GPU would fail spectacularly at a lot of things. They'd probably run EMACS worse than a Pentium II - GPU processors are relatively bad at branch or jump instructions, something general-purpose programs use quite a bit.

    23. Re:Umm... by amicusNYCL · · Score: 1

      a Radeon HD 6990 has, if my data is correct, 3072 cores running at 830mHz

      That is re-goddamn-diculous. Thanks, I guess that answers my question.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    24. Re:Umm... by wintertargeter · · Score: 1

      Wow you really know nothing about encryption. Sigh.. Everyone is an expert. Zdnet looked at ighashgpu that's unsalted password decryption when you already have a precomputed hash table. TH looked at salted password decryption where you have to perform a SHA-1 transformation invocation thousands of times per every password attempt.

    25. Re:Umm... by Sulphur · · Score: 1

      Wow you really know nothing about encryption. Sigh.. Everyone is an expert. Zdnet looked at ighashgpu that's unsalted password decryption when you already have a precomputed hash table. TH looked at salted password decryption where you have to perform a SHA-1 transformation invocation thousands of times per every password attempt.

      Experts -- What do they know?

    26. Re:Umm... by muckracer · · Score: 1

      > Experts -- What do they know?

      Enough to tell you in excruciating detail why they were wrong! :-)

    27. Re:Umm... by muckracer · · Score: 1

      > Does anyone else remember the days when slashdot readers
      > were technical? This discussion is fucking painful.

      Well, in the enterprising tech spirit feel free to establish:
      "Slashfork.org - News for real Nerds, Stuff that used to matter!" :-)

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

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

    1. Re:I wonder by Anonymous Coward · · Score: 0

      Not a chance. Slashdot has become king of reposting articles and being 3 days late on news that everyone else has broken.

    2. Re:I wonder by Random2 · · Score: 1

      Isn't that the point of the 'recent' tab? To identify dupes and vote them down?

      --
      "Our goal each year should be to increase the number of goals we set for ourselves!"
    3. Re:I wonder by Anonymous Coward · · Score: 0

      Full disclosure: I lolled.

    4. Re:I wonder by jovius · · Score: 1

      More likely with enough GPU's they'll come up with perfect summaries.

      Password hacking process could be used to create completely new content - even data like images. If you can make billions of attacks per second the amount of coherent information must eventually be high enough.

    5. Re:I wonder by ruthless+reader · · Score: 1

      You may be able to if you can target the editor(s) right on

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

    this has been known since 2009....

  4. Irrelevant by Hatta · · Score: 1

    Zip and RAR encryption has never been trustworthy. Let me know when they can crack GPG.

    --
    Give me Classic Slashdot or give me death!
    1. Re:Irrelevant by vidnet · · Score: 1

      The quoted billion passwords per second was for ancient Zip 2.0 encryption.

      The actual numbers for modern RAR encryption (from TFA) is 14605/sec.

      That's an average of 4 years for a random 7 character alphanumeric password, or 200 years for a 8 character one.

    2. Re:Irrelevant by FunkyELF · · Score: 1

      Alphanumeric would be 62 different characters.
      going from seconds to minutes to hours to days to years for a 7 character password....
      62 ** 7 / 14605.0 / 60.0 / 60.0 / 24.0 / 365.0 results in 7.6459888127245952

      So its actually around 7.7 years but thats with just one computer.
      If you had 7.7 computers, it would take a year.
      If you got a shitload of time on Amazon (which I hear has GPU rigs available for rent) you could shrink that time way down.

  5. WinRar question... by MobileTatsu-NJG · · Score: 1

    I've been told before that WinRar's encryption wasn't much to crow about, but this article says it's 128-AES. So.. which is it? Is it fairly secure (provided it is used properly...) or does it still have a major weakness that makes it easy to get into?

    --

    "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

    1. Re:WinRar question... by Anonymous Coward · · Score: 0

      The AES key can have 128 bits of entropy but if the password that generates that key only has four bits of entropy then it doesn't matter how awesome AES is.

    2. Re:WinRar question... by MobileTatsu-NJG · · Score: 1

      Right, but that's not what I'm asking. I'll be more specific: Is using WinRar with a 8+ character password reasonably secure or does it have another vulnerability that weakens it? This article suggests that it's pretty darned secure. BUT... this is a benchmark article, not a strength of security exercise.

      --

      "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

    3. Re:WinRar question... by Anonymous Coward · · Score: 0

      WinRAR is quite secure, given a secure password. You probably remember hearing about the old Zip 2.0 encryption scheme, which is incredibly weak. WinRAR can open it, but doesn't use it by default.

    4. Re:WinRar question... by Anonymous Coward · · Score: 0

      I've been told before that WinRar's encryption wasn't much to crow about, but this article says it's 128-AES. So.. which is it? Is it fairly secure (provided it is used properly...) or does it still have a major weakness that makes it easy to get into?

      The AES-128 encryption bit is probably fine.

      The problem likely lies in key management and key generation. For instance, unix password hashes used to only look at the first 8 characters that the user entered. How does WinRar generate the 128 bits needed for the AES-128 key? Do they discard data or do other things to the passphrase before it is converted into a 128-bit key?

      (Basically, getting the encryption algorithm correct is easy as long as you use something like AES-128 or another peer reviewed algorithm. Key management is at least a few orders of magnitude harder, usually because humans are involved in the process. They keep inventing smarter idiots.)

  6. 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 Anonymous Coward · · Score: 0

      And how do you keep the keyfile secure?

      Genuine question... I know people suggest SSH'ing using keys... is that more secure than having a 1 second delay between login attempts, or a firewall that only accepts local LAN connections?

      Yes people misuse passwords... but imagine someone uses passwords *correctly*.

    2. Re:This is why you use encryption programs... by chemicaldave · · Score: 1

      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.

    3. Re:This is why you use encryption programs... by Anonymous Coward · · Score: 0

      Security is multi-layered. Asking if one method is better than another suggests you could not or should not do as much as your access requirements allow.

      But to answer your question, keyfiles, at least the openssh ones, allow you to password protect them. The advantage to this being the password itself is not sent over the wire.

    4. Re:This is why you use encryption programs... by mlts · · Score: 1

      There are multiple ways to brute force. One is just finding the known subset of the keyspace (what people can type in), and running scans through that. Another is using dictionaries (ye old Crack). Of course, using dictionaries, then scanning the keyspace is useful too.

      Dictionaries are still useful even though people's passwords tend to more than just a word these days. A lot of people use two words and a character, so that is far more gussable than trying to just brute force every single option in a 10-12 character keyspace.

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

    6. Re:This is why you use encryption programs... by Caratted · · Score: 1

      You probably mis-read the parent.

      Brute force is synonymous with checking the keyspace against a dictionary.

      Architecture allows for the GPU do to this much more quickly, with the correct software. It is, however, still checking against a dictionary. Parent mentions encrypting what has already been encrypted (note the use of the word symmetrical), so that you must crack the whole keyspace, as opposed to the area of the encrypted file that you know contains the reversible hash (or, as opposed to just getting a prompt you're allowed to guess at a limitless number of times).

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

    8. Re:This is why you use encryption programs... by Anonymous Coward · · Score: 0

      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?

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

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

    11. Re:This is why you use encryption programs... by Jahava · · Score: 1

      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.

      And I fail at HTML... 1024 ^ 10 ~= 1 * 10^31.

    12. Re:This is why you use encryption programs... by Rich0 · · Score: 1

      I think you meant 2^256 in your second example. Technically, bruteforcing that probably is easier with a GPU, kind of like how you can get to Alpha Centauri faster in a galleon than by walking.

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

      256^32 == 2^256...

    14. Re:This is why you use encryption programs... by zzsmirkzz · · Score: 1

      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.

      Maybe I'm just not thinking hard enough about this but it seems very trivial to me to create a password/passphrase hashing algorithm that wouldn't be limited as you defined. Yes, there may be about 70 possible characters that can be typed - but their placement in the password (1st, 4th or 17th character) can also used to increase the possible keyspace.

      Additionally, the length of the key (256-bits) and the length of the passwords do not have to be identical - the password can be much longer and thus can have a greater keyspace. Meaning using password/phrases (or limiting access to typable characters) doesn't necessary limit the keyspace - it only may be for passwords under a certain length using a particular mapping algorithm.

    15. Re:This is why you use encryption programs... by Anonymous Coward · · Score: 0

      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.

      What do you protect your 256-bit key with? You obviously can't store it in plaintext anywhere on an electronic device that might be compromised. You can use hardware key fobs, TPM modules, sticky notes, smart cards, etc. All of those have similar problems protecting the secure key from attackers. Even using public key cryptography requires the private keys to be secured in some way.

      Ultimately the best known method of protecting private information like cryptographic keys is a secret known only to the owner of the public key; a password. Pass-phrases are even better because it is much easier to add entropy to a memorable passphrase. diceware pass-phrases are a reasonable method of choosing secure passphrases, although a 5 word diceware pass-phrase only has about 65 bits of entropy which is probably a little short today. Change the case of a letter or two in each word for an extra bit of entropy per letter, and insert numbers/symbols between words for another couple bits per insertion. Add a sixth or seventh word if you want even more bits. It should not be hard to create a memorable pass-phrase with over 80 bits of entropy. While a far cry from 256 bits, it is unlikely to be brute forced by anyone short of a national agency within the next couple decades.

      Using PBKDF2 to protect the data key further increases the work needed to brute force the password/pass-phrase space. Although in the case of archives it makes little difference whether a 256-bit random key is generated for data encryption or if the PBKDF2 derived key is used directly. There are no known weak keys for AES which means that the extra step of decrypting the 256-bit key with the PBKDF2 key corresponds to only a tiny fraction of the total workload for an attacker without any significant benefits, especially if the encrypted 256-bit data key is sent along with the archive. A benefit of using the PBKDF2 derived key is that there is less need for a source of secure random bits in the encryption utility. If there is a problem obtaining 256 cryptographically random bits during the key generation process then no passphrase will be sufficient to protect the contents of the encrypted file. The recent attack on Debian and Ubuntu ssh keys due to improper cryptographic random number generation should serve as a reminder that cryptographic randomness is hard and should only be relied on if absolutely necessary.

    16. Re:This is why you use encryption programs... by Anonymous Coward · · Score: 0

      There are multiple ways to brute force. One is just finding the known subset of the keyspace (what people can type in), and running scans through that.

      Brute force means to try all possible combinations. Restricting it to a subset of values is more along the lines of a Permutated Dictionary attack.

      Dictionaries are still useful even though people's passwords tend to more than just a word these days. A lot of people use two words and a character,

      When we say "Dictionary" we do not mean "Webster's Dictionary of the English Language". We mean a list of pre-generated passphrases to try, as opposed to just trying all possible combinations.

      Most tools which do a good job attacking password files use a combination of dictionary and brute force methods.

    17. Re:This is why you use encryption programs... by WuphonsReach · · Score: 1

      Dictionaries are still useful even though people's passwords tend to more than just a word these days. A lot of people use two words and a character, so that is far more gussable than trying to just brute force every single option in a 10-12 character keyspace.

      Specifically: 10,000 * 10,000 * 90 - assuming that both words are in the set of 10,000 commonly used words. If you assume uncommon words are in use, you may have to look at 200-300k words for each position unless you know that they stuck to the shorter words.

      --
      Wolde you bothe eate your cake, and have your cake?
    18. Re:This is why you use encryption programs... by WuphonsReach · · Score: 1

      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.

      Except that your passphrase is not 80^42 (8.5e79 or about 265 bits) possibles. It's more like (10,000^7) * 2 * 12 (2.4e29 or 97.6 bits) because all of the words are fairly common ones and probably exist in a shortened dictionary of the 10,000 most common words. They're also all lowercase, except that the first is capitalized half the time (which is the x2 factor). Humans tend to always put spaces between words in a passphrase, and they tend to use whole words instead of fragments or misspelled versions. And if there's punctuation on the end, it's usually one of about 12 possibilities (which is the x12 factor).

      No matter how long an individual word is, if it's a common word then it only has about 13.3 bits of entropy at the upper end. And if it's a shorter word, that could be as little as 3 bits per character. If it's a rarer word, then it might be one out of 300,000 (18.2 bits per word).

      It gets worse if it's a popular phrase, or if you can use a Markov chain to predict what word is likely to follow the previous word. Which makes your searching more efficient.

      --
      Wolde you bothe eate your cake, and have your cake?
  7. So.... by Anonymous Coward · · Score: 0

    Someone worked out how to scan a billion entries in a rainbow table per second using a GPU?

    1. Re:So.... by wintertargeter · · Score: 1

      rainbow tables only work on unsalted passwords. These were used by microsoft for 'lan' style passwords. IIRC, vista and win7 don't use these. And if you use a 14 character password or longer, even windows xp disables the lan encryption. Your rainbow tables are effectively useless against aes-128, aes-256, and even des. They simply precompute password hashes, and generating the tables takes quite a long time. Using rainbow tables has nothing to do with gpu acceleration.

  8. Slashdot has no credibility on this topic by Anonymous Coward · · Score: 1

    Didn't we hear about this a week or two ago?

    It was a slightly different entry in /.'s series on "passwords are dead! oh noes!", except it was on brute forcing hashed passwords. It makes the same fundamental mistake that comments on that post pointed out _repeatedly_.

    This is on brute forcing data encrypted with a symmetric cipher whose key is derived from a password. Yes, if you naively translate the password into a key, you go from a 128 or 256-bit keyspace to about the size of the dictionary.

    Crypto 101: if you're deriving a crypto key from a password, you either need to do many rounds of encryption or use a stretchable hash function to derive the actual key.

    Passwords aren't dead. If you force the attacker to take seconds of time for each password, moderately complex passwords are still not breakable.

    What we really need are crypto libraries that also use the GPU so that we're not at a disadvantage compared to the attackers. In a nutshell, we need our stretchable functions to be implemented in OpenCL.

    1. Re:Slashdot has no credibility on this topic by Anonymous Coward · · Score: 0

      The "on this topic" was unnecessary in your title.

  9. Commonsense PW Acceptance Limits? by BoRegardless · · Score: 0

    So why don't more systems lock you out after 3 tries for another 10 minutes or an hour?

    That would deny brute force attacks.

    1. Re:Commonsense PW Acceptance Limits? by jonbryce · · Score: 1

      Not much use if you have a password protected .zip or .doc file as you aren't using WinZip or MS Word to check the password.

    2. Re:Commonsense PW Acceptance Limits? by Dog-Cow · · Score: 1

      The article (or even the summary) is not talking about repeatedly attempting to log in to a system. It's talking about encrypted files.

    3. Re:Commonsense PW Acceptance Limits? by wintercolby · · Score: 1

      If they're brute forcing against a hash, attempts/failures is irrelevant. If they're brute forcing file encryption, once again, system lockout attempts are irrelevant unless it's integrated into the operating system.

      --
      Most ignorance is vincible ignorance. We don't know because we don't want to know. --Aldous Huxley
    4. Re:Commonsense PW Acceptance Limits? by Anonymous Coward · · Score: 0

      Seriously? This only works when the data and authentication software is external to your own PC because there's a layer of security between you and the data. If you have a raw piece of data on your own PC there's nothing that can stop you brute forcing the password.

    5. Re:Commonsense PW Acceptance Limits? by vlm · · Score: 1

      So why don't more systems lock you out after 3 tries for another 10 minutes or an hour?

      That would deny brute force attacks.

      Copy the file of passwords to your local machine, then hash against that file using software than intentionally does not implement such a delay.

      Heck if you have access to backups, or vmware images, or backups of vmware images, just copy and NOP out the delay code...

      --
      "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
    6. Re:Commonsense PW Acceptance Limits? by NevarMore · · Score: 1

      How am I going to enforce that on an encrypted file possessed by someone who is trying to decrypt it against my wishes?

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

    1. Re:Why none of this matters! by wintertargeter · · Score: 1

      Right... except that anyone who has a desktop gaming system can do what TH did. It's not like they had a supercomputer.

  11. Makes you wonder about Bitcoin by GoodNewsJimDotCom · · Score: 0

    Do you want to mine for Bitcoin, and get .0001 Bitcoin per hour? Or do you want to mine Bitcoin passwords and possibly get tons of Bitcoin per hour? Seems all you need is people's login name who has a lot of Bitcoin. Oh and you have to be a thief, which precludes anyone who has morals.

    1. Re:Makes you wonder about Bitcoin by martok · · Score: 0

      Bitcoin currently has no passwords. If you get their wallet.dat, it's all over.

    2. Re:Makes you wonder about Bitcoin by DanTheManMS · · Score: 1

      Exactly what accounts do you think you're cracking the passwords to? What login name are you referring to?

  12. Why are GPUs faster? by erroneus · · Score: 1

    I gotta ask why GPUs are faster? And because they are faster, why aren't CPUs using methods and techniques similar to GPUs for getting certain things done? I remember the days of the "math coprocessor" that the math processor was used to help speed things up by performing math on-chip rather than by using subroutines in software.

    I was always under the impression that GPU means graphics processor unit, not "Guessing Passwords Unit."

    1. Re:Why are GPUs faster? by FooBarWidget · · Score: 1

      These days there are GPGPUs with GP standing for "General Purpose". They're not only used for displaying graphics anymore but for general-purpose vector calculations. GPUs are faster *for vector calculations* because most of the chip consists of arithmetic units. In return, GPUs are much, much worse at pretty much everything else, such as branching. Don't try to run if-statements on GPUs.

    2. Re:Why are GPUs faster? by Stavr0 · · Score: 1

      My naive interpretation of this: http://www.nvidia.com/object/GPU_Computing.html

      In effect, having a good,recent GPU is the equivalent of having hundreds of CPUs all in one single chip. Since password guessing is a task that can be divided easily, the GPU is 100x faster than a regular CPU, and it is very efficient at number-crunching.

    3. Re:Why are GPUs faster? by Anonymous Coward · · Score: 0

      GPUs are stream processors. They are really good at doing the exact same operation on lots of values at once. If you actually only wanted to do the operation on one piece of data, they are at least an order of magnitude slower. They are really bad at any variations based on data. If your algorithm has any control flow in it, it will probably not work well in a GPU. Also, GPUs work well only with very specific memory access patterns. Doing an operation to all of memory is fast. Doing an operation that requires jumping around memory based on data is slow.

      GPUs definitely do seem to be becoming the next-generation math-coprocessor. AMD and Intel have both been working on multi-core chips with both CPU and GPU cores. Back in the old days, math coprocessors added the ability to do floating point operations in hardware. Now GPUs support doing operations involving lots of floating point numbers in hardware.

    4. 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?
    5. 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
    6. Re:Why are GPUs faster? by Solandri · · Score: 1

      Cryptography is one of just a handful of embarrassingly parallel computing problems (3D graphics is the most notable one). For the vast majority of things people use computers for, a not-so-parallel general purpose CPU is better.

    7. Re:Why are GPUs faster? by Anonymous Coward · · Score: 0

      Its simple.

      Lets say you want to add two numbers. But lets say that is all you do.

      You do not need to dedicate silicon to say subtracting numbers.

      Now also instead of doing 1 add at a time lets say you need to do 1000 adds at a time (fairly common with linear algebra and 3d type programs). A general purpose cpu would line up each one and do each add sequentially.

      Lets say it takes 1 tick to add.

      With a GPU you line up all 1000 adds to go and 1 tick later you have 1000 numbers added. With a regular CPU it took 1000 ticks. That is excluding overhead such as setting up the memory space and checks.

      Now lets say you want to branch. The GPU can not do that very well. But a regular CPU it is easy as that sort of thing is built in and helps make your code size small and cache rates better. Some of the newer GPUs have branching (in the form of shaders which are just small program fragments).

      For example the x86 arch has a bunch of singleton commands which do some of this sort of thing. Like you want to add 8 numbers together there is a single command for that. GPU's on the other hand have silicon setup to 200+ adds at once.

      GPU like things are going into the CPU (MMX, SSE, etc). But there just is not the real estate for it on the scale a GPU does it. GPU's on the other hand are trying to solve a fairly narrow problem and have the real estate for it but lack other functionality that general purpose CPU has.

      So to answer your question yes they are starting to do it and have been for several years. It is called SIMD. http://en.wikipedia.org/wiki/SIMD

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

    9. Re:Why are GPUs faster? by nospam007 · · Score: 1

      But the important thing. Did they crack the Wikileaks insurance file or not?

    10. Re:Why are GPUs faster? by Anonymous Coward · · Score: 0

      I think you got that backwards:

      CPU is the ferrari, it is fast, but has a tiny trunk.
      GPU is an 18-wheeler, goes just fine, but carries a ton of stuff with it.

      GPUs do the same operation on tons of data simultaneously, it is what they were designed for. So even though each step is slower than with a CPU, they are doing that step on many simultaneous guesses, thus the throughput is greater.

    11. Re:Why are GPUs faster? by JamesP · · Score: 1

      This analogy works (if you think the GPU is around 500MHz/1GHz and the CPU is at 3GHz)

      But I prefer the other way because for example, GPUs would probably suck at SQL, or parsing XML, whereas the CPU can just 'deals with it'

      Of course, analogies are never perfect

      --
      how long until /. fixes commenting on Chrome?
    12. Re:Why are GPUs faster? by JamesP · · Score: 1

      Since you don't know the plaintext, it's impossible, even by bruteforce

      In the case of Zip, you know some metadata (like zip headers) and I guess it uses known data from file formats or checksums

      One is AES->Zip->Data, wikileaks is AES->??

      --
      how long until /. fixes commenting on Chrome?
    13. Re:Why are GPUs faster? by Fnord666 · · Score: 1

      Since you don't know the plaintext, it's impossible, even by bruteforce

      Not really. For example we might assume that the original file is a .txt file and that the document is in English. Based on this we could perform a sample decrypt followed by a quick (relatively speaking) analysis looking for characters in the ASCII printable range. If the key is wrong the result should appear random. At the same time we can check for non-varying bytes that occur at certain positions in word documents, or for image file format headers. Most file formats don't try to disguise themselves and are easily detected.

      --
      'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
    14. Re:Why are GPUs faster? by Anonymous Coward · · Score: 0

      Well, as far as math co-processors for the x86 go, AFAIK they were essentially floating-point units. There are still FPUs, but they've been integrated on the x86 CPUs since the early 90's.

    15. Re:Why are GPUs faster? by Anonymous Coward · · Score: 0

      I gotta ask why GPUs are faster?

      There are some alright replies to your question, but people are missing part of the picture.

      Your CPU is busy doing a lot of stuff even when it's mostly idle. It has a small cache, has to juggle multiple system processes not to mention user applications, and all that ends up competing for clock cycles and time/space on the system bus.
      (note- this next sentence is a bit of an oversimplification). Now your GPU is actually a board with multiple processors and has it's own memory and internal bus. You can essentially load it up with your processing task and just let it go to town, without being interrupted or having to contend for resources.

      To be blunt, GPU's are not the best solution for busting passwords in terms of raw performance. With a small amount of know-how and a fairly small budget you can build a custom board that will kick the snot out of the best GPU's in terms of password cracking... but most people can't do that.
      GPU's have several 'advantages'. First, they are already available. Second, selling (or buying) them does not usually earn you an "interview" with black-suited Government Agents like a dedicated crypto board would. And Third, the older models are getting fairly cheap these days so there's not much of a barrier to entry.

      Any serious cracker will use a custom board because you can just keep stacking more in your chassis (as long as you have room and power) where most GPU's available to consumers really only can have one (sometimes two) per motherboard.

    16. Re:Why are GPUs faster? by Anonymous Coward · · Score: 0

      What? Thats completely untrue. That only makes sense if the size of the data is small relative to the block size of the cipher. The data in question is orders of magnitude longer. There are only 2^256 keys and thus 2^256 possible outputs from the decryption function, but the message space is probably over 2^1000000000 (several GBs). The probability that you would get a meaningful output (i.e. low entropy) with the wrong key is vanishingly small since the ratio of the output space to the number of keys is so large.

    17. Re:Why are GPUs faster? by Anonymous Coward · · Score: 0
    18. Re:Why are GPUs faster? by JamesP · · Score: 1

      Interesting, that's what I thought.

      So the most secure thing to do would be having random bytes at the beginning of the AES file

      --
      how long until /. fixes commenting on Chrome?
  13. Yes, yes... by danielpublic · · Score: 1

    "Omg, what am I going to do about my eight char password I use half across the Internets?"

    Well...
    One could print out a passwordcard.
    Then one might start using passwordmaker, to whatever phone/OS one fancy. By which time one (sh/c)ould check if ones passwords are long enough and while this "one" is at it, have a look at these tricks from an almost "tl;dr-ish" list. Now, apply elbow grease and a bit of go figure. "Problem solved? Moving on?"

    Oh, who am I kidding? Then all those (fear) mongering polemics would have to starve and we cant have that now can we? *fancifying tinfoilhat*

    --
    "If terrorists hate us for our freedom, does that mean they're slowly starting to like us?" -- Philosoraptor.
    1. Re:Yes, yes... by Bengie · · Score: 1

      A 15 char pass phrase is much more secure than an 8 char password. All it takes is a nonsensical pass-phrase and a light peppering of special chars and no one could break it without having a few dedicated power plants to supply electricity to their GPU cluster.

      $5 wrench would work better.

    2. Re:Yes, yes... by ErikZ · · Score: 1

      Oh wow. Imagine what a Beowulf cluster of $5 wrenches could accomplish!

      --
      Democrats or Republicans. They are both taking us to the same place and they are not afraid of us anymore.
  14. Real encryption by martok · · Score: 1

    With the recent MTGox compromise, I've been looking at a better password system. It looks like one way to go is to use a program like password safe or keesafe to generate unique passwords per website. However, I'm curious as to how resistant these master files are to GPU attacks. GPUs basically sliced through the MTGox MD5 hashes like butter. How long would it take a higher-end distributed cluster to break a Password Safe master file? It's blowfish encrypted I believe.

  15. another slashvertisement by Anonymous Coward · · Score: 0

    yes this is a dupe, but when GPU companies selling cards for $600 etc start throwing around payoffs many sites answer. solution? dont buy cards over 100 bucks

    video cards used to cost 30 bucks, until a few companies decided to charge more.
    a sure sign this is astroturf designed to drum up sales? just read the tag.

    "Some of their results are really fast — in the billions of passwords per second — and that's only with two GTX 570s!"

    ORDER YOURS TODAY WHILE SUPPLIES LAST!!!

    1. Re:another slashvertisement by PitaBred · · Score: 1

      ...really? Some of us play games on the GPUs, too. Or *gasp* do actual work with them! And the more expensive ones are faster. Because that's how technology works. No, not everyone needs an F1 car. Most people would be fine with a Corolla. And the cheaper cards generally give you much more value for your money. But if you can't see where some people would be more concerned about absolute performance than pure economy, then you're stupid.

      This is not a slashvertisement. This is simply tech journalism. Or is Car & Driver just a big advertisement? Is ANY special-interest magazine or site "just an advertisement"?

  16. 7z by Anonymous Coward · · Score: 1

    Which tool can crack 7zip passwords?

  17. Relevance?! Which client/server can handle that?! by G3ckoG33k · · Score: 1

    Where is the practical relevance?!

    If done over a network I guess it would generate a kind of traffic no server could handle.

    In forensics, yes. But where otherwise?!

  18. Re:Relevance?! Which client/server can handle that by wintertargeter · · Score: 1

    They did this on a desktop gaming system. It wasn't a supercomputer.

  19. Re:Can someone explain by icebraining · · Score: 1

    is there some sort of fundamental hardware/architecture difference that makes them better suited to this task?

    This. GPUs have dozens of cores optimized for parallel computation.

  20. 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
    1. Re:Password length matters by Anonymous Coward · · Score: 0

      x is the number of possible characters or number of characters used in the password ?

      eg both "1121" and "1357" are numeric passwords with the same character space. one has repeats, does it make it less secure?
      an upper and lowercase that uses only lowercase chars, is it less secure than one using both?

    2. Re:Password length matters by Anonymous Coward · · Score: 1

      Assuming an alphanumeric search space is naive. There's actually (26 *2) + (10 * 2) + (11*2) -> 94 characters that can be typed on a US PC keyboard, far more if you add all the composable characters (over 30k). For example the default settings for the (not-quite) standard mkpasswd utility generates a password with four lowercase characters, two uppercase characters, two numbers, and one typable symbol. That's not quite 94^9 -> 572,994,802,228,616,704 or 5.73E+17 permutations, not quite because you can early-exit on any string containing more than the required quota of each character class, assuming you know the password has been generated under that class of conditions. This gives an average break every 286 million seconds or 9 years, assuming a billion hash-checks per second.

      On this information, it would be wise to use a larger password permutation space, as that 9 years can easily be reduced to months or weeks by a determined and well financed adversary. This only applies for situations where the advesary knows the hash, as in the example in the article of encrypted archives or documents, it doesn't affect the security of systems where the rate of password tests is limited by an external system, such as SSH login attempts.

      It is also a good idea to salt user supplied passwords with a computationally expensive random pad, for example if the last 32-bits of the key are generated randomly during encryption, and subsequently discarded, and exhaustively iterated when decrypting, it makes it 4 billion times more expensive for both the adversary and the user, however for the user that 4 billion times expense is only on the order of one second, as the rest of the key is supplied, however for the adversary it multiplies every guessed attempt by 4 billion.

    3. Re:Password length matters by Anonymous Coward · · Score: 0

      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.

      Cool, I'll add an 'a' to the end of my password every 12 years then :-)

    4. Re:Password length matters by WuphonsReach · · Score: 1

      My estimates have always been: 10,000 commonly used words, 200-300k in a large dictionary.

      Most people tend to pick words that are familiar to them, that they probably use in everyday speech or hear regularly. Not many will crack open a random dictionary or book and pull a word out at random from the other 97% of the word list.

      Now, identifying the 3% most commonly used words? That's a bit more of a guessing game.

      --
      Wolde you bothe eate your cake, and have your cake?
    5. Re:Password length matters by pugugly · · Score: 1

      Yes but the point is that (barring quantum machines) adding length (y) increases the permutations (and thus the size of the search space) at a far greater speed than adding characters (x). It also happens to be much for a human being to do rather than pulling out esoteric unicode characters that may or may not be legal characters in a given system.

      Pug

      --
      An Invisible Entity of Vast Power whose existence must be taken on faith alone: Liberal Media
  21. Re:Relevance?! Which client/server can handle that by Anonymous Coward · · Score: 0

    Cracking archive passwords; although as best I can tell those are primarily used only by spammers releasing fake warez.

  22. Re:Bridge jumper paralyzed after landing on boat by Anonymous Coward · · Score: 0

    Further examination tells us that over 3000 people in China were taking a shit at the exact same time.

    Coincidence?

  23. Great. by Anonymous Coward · · Score: 0

    I can finally unpack all that passward-protected warez from 1999.

    1. Re:Great. by WiiVault · · Score: 1

      Haahaa I actually was thinking the same thing.

  24. I mean... by Anonymous Coward · · Score: 0

    I think everyone should panic, they're taking over... and we're selling them to you.

    http://www.ccny.com/

  25. Re:Relevance?! Which client/server can handle that by Anonymous Coward · · Score: 0

    True, this is a case of one metric tested on a closed system being projected into the rest of networking and the internet. If you were to try this over an external connection, even that of a closed network, you will see those numbers drop off drastically. Adding a simple fix like limiting the number of log-on attempts in a time period stops this measure cold. It doesn't matter if you can cycle through 10,000 combinations in a second if the server locks you out after ten.

  26. In Soviet Russia by Roachie · · Score: 1

    Brute cracks YOU!

    --
    This sig is not paradoxical or ironic.
  27. When's it going to be useful for me? by Anonymous Coward · · Score: 0

    I'd like it to speed compile times.
    I like Gentoo and all but I'd really like it if building the thing got faster.

  28. passphrase by Anonymous Coward · · Score: 0

    I started using a passphrase for my personal computer, and it is easier to remember, more natural to type since I can touch type, and exponentially more secure. In fact, my passphrase is "4 score and 7 years ago...", which is much more secure than "4sa7YA". Try cracking that one!

  29. Re:Relevance?! Which client/server can handle that by WuphonsReach · · Score: 1

    Where is the practical relevance?!

    When you design a security system that relies on passwords - you need to make the assumption that the attacker has either the password hash or the binary file that is being protected. In which case, they are not subject to any delays or lockouts and they can ramp up the brute-force rate to whatever they can afford. They may even have access to a 10k machine botnet, in which case their resources will far exceed your own. So you should also make the assumption that the attacker has more resources then you, probably at least 1-2 orders of magnitude more then you do.

    It doesn't require all that much more effort to make sure you can survive against an attacker who can run a brute-force rate of a few billion attempts per second. Mostly, you just make sure that minimum password lengths are increased out to 10 or 12 characters and that you enforce complexity rules. Don't allow users to enter short passwords that are dictionary words. Maybe even maintain a list of the top 10,000 known passwords in the wild and check against that list before accepting a user's password.

    Secondly, you make sure to store the passwords as hashes (not plaintext) and that you use a unique salt (of at least 12-16 bits) for each account. That way, if the hashes are stolen, they can't just generate a single rainbow table for the entire password list. Instead, they will have to brute force each individual password by itself.

    Third, you need to design the system so that it never sends hashes over the network where they can be sniffed. And make sure that all communication is over encrypted channels.

    --
    Wolde you bothe eate your cake, and have your cake?
  30. Re:Relevance?! Which client/server can handle that by c0nner · · Score: 1

    Using GPUs to crack passwords isn't going about it the same way that you are thinking. There are no network connections to a server as the GPUs wouldn't be any faster at that than a normal CPU. What they are doing is getting a copy of the encrypted passwords in some way. Either from a workstation with cached passwords or gaining some amount of access to system to get a hold of the encrypted passwords. Then they run the cracking software against that local file using the GPUs to do the heavy lifting.

    Back in the mid 90's I remember we ran a quick little utility on the windows nt box connected to the domain and it gave us a file that could then be passed to a cracking program. After the initial dump it didn't need network access and just sat there churning away spitting out passwords as they were found. It took progressively longer the more characters there were in the password.

    Fast forward 10 years and the methods used to encrypt the passwords has gotten much better to the point that even a multi core CPU just couldn't make enough headway in a short amount of time without using something like a super computer or HPC cluster. Then move forward to GPU computing where you can throw thousands of little cores that are really good at checking passwords into a single computer and you move from needing racks of servers to a decent desktop with a few GPU cards to do the same work.

    So why is this relevant if you have to get into the system first to get the file. Well the answer to that is you only have to find one weak link in an organization to get a hold of the encrypted passwords for the entire system. So if you can convince one normal user to run malware that harvests that file and sends it off site you can work on cracking it at your leisure.

    We recently threw our password file at a single Nvidia Tesla M2050 card and we were able to get all the passwords with 8 characters in just a few hours even with complexity requirements. We were able to do pretty much anything under 13 in a few days. It prompted us to change the encryption on passwords stored in ldap as a result of it.

  31. did I not get it? by Anonymous Coward · · Score: 0

    ask for phone confirmation if more than 30 attempts have been made in 1 hour. How will GPUs help now?