Forgot your password?
typodupeerror
Security Supercomputing IT

Cracking Passwords With Amazon EC2 GPU Instances 217

Posted by CmdrTaco
from the sekrit-p4ssw0rd dept.
suraj.sun writes "As of Nov. 15, 2010, Amazon EC2 is providing what they call 'Cluster GPU Instances': An instance in the Amazon cloud that provides you with the power of two NVIDIA Tesla 'Fermi' M2050 GPUs... Using the CUDA-Multiforce, I was able to crack all hashes from this file with a password length from 1-6 in only 49 Minutes (1 hour costs $2.10 by the way.). This is just another demonstration of the weakness of SHA1 — you really don't want to use it anymore."
This discussion has been archived. No new comments can be posted.

Cracking Passwords With Amazon EC2 GPU Instances

Comments Filter:
  • by intellitech (1912116) * on Tuesday November 16, 2010 @12:31PM (#34243298)

    But, regardless of the hash method, 6-character passwords are ultimately worthless.

    • Why is SHA1 deprecated?...

      Just cause it's stupid to rely on it for obfuscating stored passwords doesn't mean it's still useful for tasks it is more suitable for.

      • Re: (Score:3, Interesting)

        by Omnifarious (11933) *

        While this article really has nothing to do with the security of SHA-1, SHA-1 does have weaknesses that should make anybody think twice before using it.

        And I really hate it when people say "Oh, well, it isn't good for this, but how about this?! I mean, we can't toss out a perfectly good algorithm!". What possesses people to hang onto algorithms that are broken for which there are essentially drop in replacements for that aren't.

        Hash algorithms are really tricky to use correctly, and know when you can and

        • Re: (Score:3, Insightful)

          by TheLink (130905)

          So just get over it already and drop the bad algorithm. How hard can it be?

          0) What algorithms do you propose as replacements?
          1) How hard can it be? Maybe you can "walk the talk" by deleting/disabling all the CA certs in your browser that use bad algorithms- e.g. algorithms that you did not propose in 0). Same goes for not using browsers, ssh servers and clients that do not support algorithms in 0).

          Don't be surprised if you find that some CAs are still using MD2!

          • 0) What algorithms do you propose as replacements?

            That is tricky. Currently SHA2-256,384,512 are the only viable replacements, but I would say that's only provisional and should wait for the results of the NIST hash algorithm competition.

            1) How hard can it be? Maybe you can "walk the talk" by deleting/disabling all the CA certs in your browser that use bad algorithms- e.g. algorithms that you did not propose in 0). Same goes for not using browsers, ssh servers and clients that do not support algorithms in 0).

            Don't be surprised if you find that some CAs are still using MD2!

            This is a completely different issue than say "Oh, it's still perfectly good for some things, you don't have to stop using it!". If someone else is using it that you need to interoperate with you don't have any choices besides not interoperating, or implementing the algorithm.

            But you still don't have to say "It's just fi

        • And replacing the stupid thing is pretty simple. So just get over it already and drop the bad algorithm. How hard can it be?

          It's not simple to replace anything that is "written" in hardware.

          It's not simple to replace an algorithm with one that is more complex (more computation cycles) when performance (or battery life) is the key issue.

          It's not simple to replace one hashing algorithm with another when you have thousands of users that must then update their passwords (and password hashes).

          It's not a convincing argument to say "replace a hashing algorithm with another algorithm" if there is no complete break in the wild for the in

          • by AndrewNeo (979708) on Tuesday November 16, 2010 @01:20PM (#34244106) Homepage

            Salt has absolutely nothing to do with collisions if you have the target hash you're trying to collide with. Finding collisions means they don't need to know the original input, it means they found some other input that creates the same hash. Salting only helps dictionary attacks against the password that created the hash.

            • by SteveAyre (209812)

              Not true... with salted encrypted passwords you're trying to find a password that the application will think is the correct one. It concatenates the salt with the password and checks whether the hashes match (simplified explanation, but that is what many implementations such as crypt do). That means you're trying to find a collision where the salt is at the start of the input that causes the collision. That's a small subset of the inputs that generate the same hash so it does make finding collisions harder.

              • Re: (Score:2, Interesting)

                I think you misunderstand what AndrewNeo was saying. When you have the hash itself, you can then try to find some input that also produces that hash (a collision). You don't have to know anything about the original password or the salt.

                As far as I can tell, salting only helps against rainbow table attacks. OP wasn't using those, he was computing the hashes (and thus finding collisions) using only the EC2 GPU instance. He was generating the tables themselves. Salt won't help you in that case. It just
                • by 0123456 (636235)

                  Salt won't help you in that case. It just requires more compute power which has now become available thanks to the EC2 GPU instances that Amazon is offering.

                  Not using a salt means you can check a complete file of passwords in the same run, since you just hash the password and check whether it matches any entry in the file. Using a salt means you can only check one password at a time, since the password will hash to a completely different value when used with a different salt (absent blind luck finding a collision).

                  If you want to crack 50,000 passwords, then you'll have to buy 50,000 times more power to do that if they're salted than if they're not.

                • Re: (Score:3, Insightful)

                  by sgtwilko (472549)

                  Correct me if I'm wrong but, Yes, what you are saying is true for hashes without salt or systems that allow you to provide an already hashed password (why would you do such a thing?), but for these you do not need the collision the hash itself will do.

                  In a system that correctly applies the salt, your new input will not generate the same hash.
                  i.e.,
                  User sets Password, Password is hashed with the salt (e.g., passwordHash = hash(salt+password) )
                  You discover the resultant hash,
                  You find a collision that produces

                  • The salt is typically added at the end, and for the MD5 hashing algorithm, two colliding passwords will still collide no matter how much salt is added.

                    In other words,
                    if MD5(password) == MD5(password),
                    then MD5(password+salt) == MD5(collisionValue+salt).

                • by nabsltd (1313397)

                  As far as I can tell, salting only helps against rainbow table attacks.

                  Adding a salt also helps to increase the original keyspace, which increases the time to brute force.

                  As an example, in TFA the source input of the hashes were all 6 bytes. If the hash had been created by adding a 2-byte salt, that means the original user-generated password was only 4 bytes...definitely not very secure.

                  Note that TFA did not exhaustively compute all SHA1 hashes in 49 minutes, but it appears to have exhaustively searched the 6-byte keyspace in 49 minutes. If you use 8-byte passwords with a 4-

        • by vlm (69642)

          While this article really has nothing to do with the security of SHA-1, SHA-1 does have weaknesses that should make anybody think twice before using it.

          And I really hate it when people say "Oh, well, it isn't good for this, but how about this?! I mean, we can't toss out a perfectly good algorithm!". What possesses people to hang onto algorithms that are broken for which there are essentially drop in replacements for that aren't.

          Hash algorithms are really tricky to use correctly, and know when you can and can't use them when they have a specific weakness is not a trivial determination to make. And replacing the stupid thing is pretty simple. So just get over it already and drop the bad algorithm. How hard can it be?

          Not to get too specific, but I use SHA-1 to generate a globally sorta-unique ID for a datapoint in multiple locations using multiple implementations by basically concatenating the relevant parts of the datapoint together and then figuring the SHA-1 hash. How is SHA-1 "broken" for this application, other than being faster and available on more systems and languages that my data importers are run on than other hash functions? I really couldn't care less if it can be reversed, but I am very interested in how

      • by epine (68316) on Tuesday November 16, 2010 @12:46PM (#34243564)

        I agree the story could have been framed better. There is in any case some story here. For certain computational tasks, the linear performance scaling that vanished in a puff of Prescott has returned from the grave.

        And not only that, instead of spending $20,000 to buy a Fermi class workstation and getting your result in a year, you can throw the same $20,000 at the cloud and have 10,000 machines deliver your result in an hour, for large instances of cloud.

        This applies to a class of computational tasks denominated in CPU cycles where you can cut a wide swath.

        Moore's law still exists, it's just not evenly distributed.

        • by FlameWise (84536) on Tuesday November 16, 2010 @01:23PM (#34244164)

          He's got 14 hashes and cracked 10 of them with passwords of length 1 through 6, some of which contain proper symbols like "P4s$" and "G0o|)".

          Length 1 through 4 take less than a second.
          Length 5 takes 31 seconds.
          Length 6 takes 2950 seconds.
          I can see why he probably didn't want to cough up for Length 7 or above.

          Amongst the passwords he didn't find was, according to Google Search: "password". Amusingly, I think one of the passwords he didn't manage to crack was the empty string.

          I figure you'd have to polish that package a bit for a real attack, but undoubtedly people already have done that somewhere and hence it's a good idea to follow his advice anyway.

          • Amusingly, I think one of the passwords he didn't manage to crack was the empty string.

            Indeed. The last line in the input file is the hash of the null string!

      • by WuphonsReach (684551) on Tuesday November 16, 2010 @01:18PM (#34244062)
        Why is SHA1 deprecated?...

        Because it has become easy to create 2 plaintexts that both hash out to the same SHA-1 value [wikipedia.org]. See the section titled "SHA-1" which talks about attacks on the hash function.

        This means that SHA-1 and MD5 are not suitable for "signing" usage where you have a plaintext where you want to prove that the original has not been changed. It's too easy for an attacker to alter the plaintext in a easily hidden manner so that the hash stays the same.

        Is it still useful for the storage of passwords? Yes, but the writing has been on the wall for SHA-1 and MD5 for close to a decade now. When one weakness is discovered in an algorithm, it's the safe bet to assume that future weaknesses will be discovered and those make make the hash algorithm unsuitable for storing passwords. Better to move to one of the newer, more complex, algorithms while you have time to plan over the course of a few years rather then have to switch suddenly in the space of a month or three after an attack is discovered.
        • by vlm (69642)

          Because it has become easy to create 2 plaintexts that both hash out to the same SHA-1 value.

          This means that SHA-1 and MD5 are not suitable for "signing" usage where you have a plaintext where you want to prove that the original has not been changed. It's too easy for an attacker to alter the plaintext in a easily hidden manner so that the hash stays the same.

          Your use of the word "easy" is a little peculiar in that you don't get to chose the matching plaintext, except in the most limited fashion.

          Most of the time you're signing a hash of a document instead of signing the document itself.
          Example "My hundred page mortgage packet", hashed down, sign the hash to prove its mine or basically stick a virtual notary stamp on it.

          It is a math breakthru to be able to generate "a file" that hashes to the same, signed value faster than random guess -n- check. The problem is

        • by robosmurf (33876)

          Because it has become easy to create 2 plaintexts that both hash out to the same SHA-1 value [wikipedia.org]. See the section titled "SHA-1" which talks about attacks on the hash function.

          Um, the very article you link to lists no found collisions, only theoretical attacks (where an algorithm could be used to find one faster than a brute force search).

          Given that I've yet to see an actual SHA-1 collision published, it's hardly "easy" to do...

    • Not quite true. They can still work providing two precautions are used: Salting to prevent precomputed tables, and a form of key strengthening (Iterated is easiest).
    • by bluefoxlucid (723572) on Tuesday November 16, 2010 @01:16PM (#34244010) Journal
      Yes that seems to be the case here. If he used SHA-256 it would still break like that; but with 7 character passwords he'd be doing 4-5 bits more just for lower case letters, 5-6 for lower/upper and numbers, almost 7 bits for upper/lower/number/hash. At 4 bits that's 16 hours.. just adding one lower case letter. With complex passwords with 8 characters, 16384 hours or about 2 years. The average case is half that of course. Good luck spending a year to break 8 characters.
  • What is this 1995? Does anyone use passwords that short for anything they care about any more? I'd be interested if they could break 6-12 char passwords with lower, upper, and special characters.

    I bet loftcrack could do this same job faster. What is the news here?
    • by falldeaf (968657) <.falldeaf. .at. .gmail.com.> on Tuesday November 16, 2010 @12:43PM (#34243518) Homepage
      Are you kidding? Everyone that isn't a 'computer person' is still using their daughter's name or the favorite type of sports car brand, one word all lower case passwords for all sites and always will. The best security advancements don't come from new theoretical math theory, they come from making security easy and convenient for average people.
      • by Ecuador (740021)

        Are you kidding? Everyone that isn't a 'computer person' is still using their daughter's name...

        Still, "Random Frequent Flier" is not crackable with this brute force method... Not to mention that other child first names can hurt the attacker - remember little Bobby tables?

        • Re: (Score:3, Informative)

          by jank1887 (815982)

          had to google it: http://www.xkcd.com/327/ [xkcd.com]

        • by WhiteDragon (4556)

          Are you kidding? Everyone that isn't a 'computer person' is still using their daughter's name...

          Still, "Random Frequent Flier" is not crackable with this brute force method... Not to mention that other child first names can hurt the attacker - remember little Bobby tables?

          nice, a Hitch Hiker's Guide ref and an xkcd ref :-)

        • by Kosi (589267)

          remember little Bobby tables?

          And how I do! Just two days ago I told a friend about xkcd and browsed to exactly that "exploits of a mum" strip later that day because of it. It always makes me laughing so hard, that's the kind of girl to marry!

      • by Dishevel (1105119)
        I do not like average people. I protect my stuff from them. I am perfectly ok with those people having their money taken out of their bank accounts and having their email account pwnd.
      • by StikyPad (445176)

        The best security advancements don't come from new theoretical math theory, they come from making security easy and convenient for average people.

        Too bad, then, that security is inversely proportional to convenience.

        • by falldeaf (968657)
          Good thing then that the goal for most people is not the absolute most secure setup possible. It's about finding a good balance between usability and security. If you're *only* worried about security then unplug it, fill it with cement and bury it in your back yard. (And don't tell anyone that you did it.)
    • Re: (Score:3, Insightful)

      by hedwards (940851)
      Indeed. Pretty much everybody that cares about password security is stuck using a password manager anyways. So you may as well use a 20 char password when allowed to. I mean that would only take what like a millennium to break at that rate?
      • by vlm (69642)

        Indeed. Pretty much everybody that cares about password security is stuck using a password manager anyways. So you may as well use a 20 char password when allowed to. I mean that would only take what like a millennium to break at that rate?

        Well the point is SHA-1 outputs a 160 bit hash, so superficially you can find "A" collision in about ( (2 to the 160) divided by 2 ) guess and checks. But it's been broken so you can find a collision in only about 2 to the 50-something ops.

        So guessing 20 characters times about 7 bits/char (unless you're going all UTF-8 on us) is 140 bits in for a hash that could be "worth" 160 bits, but now is only worth 140 bits. What you don't know is SHA-1 is only "worth" about 50 bits, lets round up to about 7 ASCII c

        • by yuhong (1378501)

          So guessing 20 characters times about 7 bits/char (unless you're going all UTF-8 on us)

          AFAIK, the NT password hash is up to 255 UTF-16 characters hashed using MD4.

      • by lakeland (218447)

        Instead of someone breaking your 20 character password, all they have to do is find a password that hashes to the same as your SHA1 hash. Because of weaknesses in the SHA1 algorithm, any password contains only approximately 8 bytes (8 characters) of data. Put another way, until we improve off SHA1 it is not particularly useful to have a password over 8 characters because it's cheaper to crack the hash than the password anyway.

        • by yuhong (1378501)

          AFAIK, the NT password hash is up to 255 UTF-16 characters (two bytes per character) hashed using MD4, which is even weaker than SHA1 or MD5. Not that you necessarily need to crack the hash, because many Windows networking protocols lets you pass it directly.

    • by MozeeToby (1163751) on Tuesday November 16, 2010 @12:48PM (#34243600)

      Maybe he wanted a proof of concept without having to spend lots of money doing it? So he can crack a bunch of 6 character passwords in an hour or so, extrapolating up, and estimating a 100 fold increase in the search space for each extra character, you might end up spending several hundred years cracking a 10 character password. Now, what's handy is that you're just renting the equipment, I don't know how many GPU setups that Amazon has available, but it doesn't seem unlikely that you could rent several hundred, possibly even several thousand, of them at a time, cutting the time to crack a significant password down to under a year, which still seems pretty secure, especially given the cost of renting that many platforms.

      But what happens in 5-10 years, after the performance per price ratio has doubled a few more times? Now you're down to maybe a single month for a wealthy individual to be able to crack a significant, real-world password. Give it another few generations of hardware and you're not even talking about a wealthy individual any more. Good luck convincing the average Joe that he needs to start remembering 15+ character passwords, especially if you're going to enforce truly random ones that aren't susceptible to more direct attacks.

      • by nabsltd (1313397)

        But what happens in 5-10 years, after the performance per price ratio has doubled a few more times? Now you're down to maybe a single month for a wealthy individual to be able to crack a significant, real-world password.

        Since an exhaustive keyspace search increases the time by 256 for each extra character (and the TFA shows about 100x increase, probably because he didn't use every character), then even if performance doubled every year (unlikely), you'd still be at about a 10 CPU-days to crack an 8-character password, and over 1000 CPU-days to crack a 10-character password. So, yeah, if computers increase in speed by more than double their current increase, and Amazon (or some other company) has enough of them to rent to

    • by fmobus (831767)

      I don't see how password length makes any difference here. Most applications naïvely store hash_function(password) in the database. If you manage to find a 4-char string whose hash is the same as the one stored in the database, it doesn't matter if the original password has 300 characters. The best course of action for any application is to store hash_function(password + secret_salt) in the database.

      • They are brute forcing the hashes. Sure the output hash length is always the same, but the number of possible inputs are signinicantly reduced by limiting password length of 6.

        Think 26^6 vs 2^160 or 308,915,776 vs 1.46E48. Quite a large difference.
      • by MtHuurne (602934)

        The kind of hashes used in password databases are a lot longer than 4 characters (~24 bits) though. The total number of hashes produced by 4-character passwords is so much less than the total number of possible hashes that the chances of a hash collision like you describe are negligible.

        Since the salt and the hash are typically stored in the same place, someone running this kind of attack most likely knows the salt too. If it's possible to try all 6-character passwords in less than an hour, that will still

  • by kiwix (1810960) on Tuesday November 16, 2010 @12:37PM (#34243412)

    This just shows one more time that SHA1 is deprecated — You really don't want to use it anymore.

    No it doesn't show anything. Your "attack" would only have been marginally slower with SHA-2, because SHA-2 is a bit slower of SHA-1. You didn't exploit any weakness of SHA-1 in this brute-force attack.

    • Re: (Score:2, Insightful)

      by gman003 (1693318)
      I think "able to brute-force thousands of passwords in an hour" qualifies as a weakness in SHA-1.
      • Re: (Score:3, Informative)

        by ZouPrime (460611)

        No, it doesn't. For any other hashing algorithm of similar speed, the same results could be obtained. It's not a weakness of the algorithm, it's a weakness of only checking for passwords of 6 characters and less. That's not a very big space.

      • by daveewart (66895) on Tuesday November 16, 2010 @12:51PM (#34243654)

        I think "able to brute-force thousands of passwords in an hour" qualifies as a weakness in SHA-1.

        Not really. It just shows that 6-character passwords aren't very strong. The hash itself is not the weak point.

      • by vadim_t (324782) on Tuesday November 16, 2010 @12:57PM (#34243750) Homepage

        No, it qualifies as weakness of the passwords.

        If your password is "password", no hash is going to save you from that. The cracker takes "password", feeds it to the hash, then compares the result to every line in the hashed password file, to check if it matches anybody's.

        Hashing itself has to be fast, since not only passwords get hashed. Sometimes you need to hash a DVD .iso, would you want that to take a week?

        Now, you can do things like making the encoding be hash(hash(hash...(password))) with such a depth that it takes a second for a single check. You can't make it much longer than that because then the users will get tired of waiting. But even then it won't save you if you're dumb enough to have "password" or your username for the password. If the attacker has 10000 accounts, it takes about 3 hours worst case (with salting) to check if any of them use "password". And with that many, chances are pretty good that at least one is. So it's still not a license to use a crappy password. That's if they're not determined enough to get a botnet to work on it.

      • I think "able to brute-force thousands of passwords in an hour" qualifies as a weakness in SHA-1.

        Then you must also think that this weakness applies to all hashing algorithms, and thus is not a weakness in SHA-1 but in hashing algorithms in general.

        "able to brute force thousands of passwords in an hour" means nothing. The ability to brute force something given less computational steps than intended means something. Throw enough CPU at any algorithm and you'll see the same brute force time-frame results from any hashing algorithm.

        I would fully explain, but I'm certain you wouldn't understand.

      • I think "able to brute-force thousands of passwords in an hour" qualifies as a weakness in SHA-1.

        Maybe that would be seen as a weakness. But what this guy demonstrated was not "thousands of password in an hour", it was "14 passwords with a maximum length of 6 in 49 minutes". Can you scale up, and crack thousands in an hour? Sure. But at the rate he did it, one password every 3.5 minutes, to get 1000 passwords in 60 minutes you would need a nearly 60-fold increase in power. He paid $2.10 for his 49 minutes, which means you're going to need to pay $126 per hour if you want the power to crack that ma

    • by Anonymous Coward on Tuesday November 16, 2010 @12:44PM (#34243532)

      No it doesn't show anything. Your "attack" would only have been marginally slower with SHA-2, because SHA-2 is a bit slower of SHA-1. You didn't exploit any weakness of SHA-1 in this brute-force attack.

      He exploited the "is fast to calculate" weakness.

      Clearly, we need hash functions which take long amounts of time to compute.

      • by mu22le (766735)

        Clearly, we need hash functions which take long amounts of time to compute.

        A no brainer: just add a sleep() here and a do_nothing() loop there...

      • by Cow Jones (615566) on Tuesday November 16, 2010 @01:36PM (#34244386)

        He exploited the "is fast to calculate" weakness.

        Clearly, we need hash functions which take long amounts of time to compute.

        You're being facetious, but this is basically what the apr1 algorithm used in the Apache webserver does. It's a modified variant of MD5, where the hashing step is repeated 1000 times in order to slow down the creation of dictionary hashes:

        /*
          * And now, just to make sure things don't run too fast..
          * On a 60 Mhz Pentium this takes 34 msec, so you would
          * need 30 seconds to build a 1000 entry dictionary...
          */
        for (i = 0; i < 1000; i++) {
                apr_md5_init(&ctx1); ....

        from apr_md5.c [apache.org], line 608

        I don't know whose bright idea that was... the comment about the speed of this routine on a 60 MHz CPU speaks for itself. But regardless of how effective such "improvements" are, we're now stuck with this algorithm if we want to support the password hashes used in conjunction with .htaccess files, for example.

        CJ

      • by blueg3 (192743)

        If only there was some sort of Password-Based Key Derivation Function that could use salted, fast-to-compute hashes and apply them many times to increase the cost of computation so that dictionary attacks are proportionally more difficult.

      • You laugh, but PBKDF2 [wikipedia.org] is the most common way to derive an encryption key from a password and it calls for looping a hash function 1000+ times, for the specific reason of making brute-force attacks take longer to do.

      • Re: (Score:3, Insightful)

        by Eil (82413)

        Parent was modded funny, but that's actually a valid security measure [wikipedia.org] and it does wonders against your garden-variety dictionary attack.

    • by ByOhTek (1181381)

      Agreed - the only thing brute force shows is the importance of good passwords.

      Aren't most hashing algorithms linear in time based on the input? In that case, all such algorithms would only vary by a constant factor, not really a difference in terms of security worthiness anyway.

      Correct me if I'm wrong, but isn't the main point of a hashing algorithm to make it unlikely that two different messages would have the same hash (in particular to make it difficult to coerce this effect and have the second message w

    • That's exactly what I thought. SHA-1 has been demonstrated to have weaknesses, not trivially exploitable ones right now, but weaknesses all the same. But what this person is doing doesn't exploit any of them. They don't get to blame the ease with which they cracked passwords on SHA-1.

      Though, as I understand it, there are algorithms that involve multiple rounds of hashing with a bit of salt added each time. Those would be good because there is no clear way to compute them faster and you can have a few hu

  • Does this mean I can no longer rely on my 6 character passwords?

    • by jeffmeden (135043)

      Does this mean I can no longer rely on my 6 character passwords?

      You still can, if your six character password is "FrodoSamwiseGandalfGimliAragornLegolas"...

    • by smithmc (451373) *

      Does this mean I can no longer rely on my 6 character passwords?

      Pfft. You fool; everyone knows that 6-character passwords are no good. You should use a 7-character password, like me!

  • SHA1 deprecated? (Score:2, Interesting)

    by Anonymous Coward

    This just shows one more time that SHA1 is deprecated — You really don't want to use it anymore

    Or you could, you know, use a salt (like any competent password system). And require eight-character passwords (like any competent password system). That will stave off obsolescence for maybe another decade.

  • by MyDixieWrecked (548719) on Tuesday November 16, 2010 @12:47PM (#34243584) Homepage Journal

    So this also proves that, ultimately, this list of passwords was not properly hashed.

    People jump up and down and scream that SHA1 and MD5 are broken, but if properly used, they still offer significant password security. One trick is to use salts when storing passwords in the database.

    password: 'foo'
    salt: '2010-11-16T08:39:05Z - some_random_string$#@!'
    password-hash (md5): 14e80778512f578a5fe263abe4b58e9c

    that increased the amount of time required to brute-force the password significantly. Also, the use of a database of hashes is largely worthless since each password in the list would have a completely unique hash. for the sake of brute-forcing the data, short passwords don't matter (on the other hand, brute-forcing login to the application is not affected). Having a different salt for each password makes the time spent on each other password completely worthless once the cracker gets to the next item in the list.

    to improve that, we can say... hash the result 1000 times in a row. For someone trying to brute force the hash, they would spend 1000x the CPU resources creating the hash. It's mostly not a big deal to run that hash 1000 times when creating the information for the database or authenticating the user.

    of course, SHA1 and MD5 are still broken when it comes to file integrity checking (when it comes to tampering) since there are documented collisions. For this case, cryptographic signatures are where it's at. You can guarantee that not only was the file not tampered with, but also that the person who supplied the signature was who they say they were. Gotta love public key encryption.

    • by fmobus (831767) on Tuesday November 16, 2010 @01:05PM (#34243854)

      While I concurred with your point somewhere else in this discussion (regarding the usage of salt), I wonder if there is any possibility that an attacker, having a sufficiently large corpus of your stored hashes, would be able to extrapolate what salt your application is using.

    • by ByOhTek (1181381)

      All of your suggestions only increase the brute-force cracking time by a linear factor.

      They are useless. Adding another character or two to the minimum password length, requiring more distinct character or requiring more character classes will all have a significantly higher affect on brute force attacks, with much less effort, and less CPU time for legitimate password entries.

    • by randallman (605329) on Tuesday November 16, 2010 @02:13PM (#34244986)
      Salts protect against rainbow tables, not necessarily short passwords. In most situations, the salt needs to be known by both parties and is sent in the transmission so that the salt is not a secret. Don't count on the salt being a secret. You still need to choose a good password. Using a salt just means an attacker won't be able to look up the hash in a rainbow table.
  • Obviously this service will be used by pirates (and not the "arrgh matey" kind), hackers and terrorists and anyone else that gets labelled as a bad person (tm), so we better pre-emptively ban Amazon as they are the ones offering it up.
  • you apparently need to throw some of that horsepower into your webserver. Amazon has some solutions there for you.

  • by sootman (158191) on Tuesday November 16, 2010 @12:58PM (#34243762) Homepage Journal

    "Using the CUDA-Multiforce, I was able to crack all hashes from this file with a password length from 1-6 in only 49 Minutes..." [emphasis mine]

    Sounds like someone missed the day they taught exponents in school.

    Pretend he only tested 72 characters: a-z, A-Z, 0-9. Going from 6 to 8 characters would make this take 5,184x longer. (72x72). 49 minutes x 5184 = about SIX MONTHS.

    • by sootman (158191)

      Oops, typo. The number '72' came from A-Z, a-z, 0-9, and the punctuation above 0-9. If you count the other punctuation on a standard keyboard the number goes up to 94, and depending on the app you might be able to use things like é and ñ which would really raise the character count.

    • by StikyPad (445176)

      Not to mention an exhaustive rainbow table search would've taken about 5 minutes on an average desktop, and as a bonus you'd likely get all passwords up to 8 chars (depending on your particular table).

    • by Timmmm (636430)

      True but he was only using a single node, and it cost him $2 or something. He could easily use a few hundred nodes and get that "SIX MONTHS" down to a few hours.

  • by mrnick (108356) on Tuesday November 16, 2010 @01:03PM (#34243824) Homepage

    As part of my graduate studies, in Computer Science at Texas A&M University, I built out a LAM/MPI - CUDA cluster. With this configuration we had access to all the CPU/GPU on all the systems in the lab. Although it requires knowledge of both API it can be extremely powerful. I'd love to see a cloud based system based upon this configuration. Now that would be worth paying by the hour to use!!!

    896 CUDA Cores (2 x NVIDIA Tesla C2050 (Fermi) cGPU) is nice but imagine the power of a data center filled with these!!!

  • Those password hashes are just SHA-1 hashes. Hashes coming from something like unix's crypt()-like functions use many rounds of hashing and therefore take that much longer to crack.

  • Sure, CPU's include a FPU these days, but in the early days between the 8086/8 you had the 8087 FPU, 286's had the 287, 386's the 387, and even 486SX's could have a 487 added (DX's had it built in). The Pentium class CPU's were the first to have all models include a FPU. Since then, all CPU's have included one.

    But now, for more intensive items, we have "physics" cards, GPU cards (which at first glance appear to be FPU's?) etc. So, is the FPU as an addon on its way back? Perhaps.

An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.

Working...