Forgot your password?
typodupeerror
Security Businesses Google The Internet

Using Google To Crack MD5 Passwords 232

Posted by kdawson
from the secrets-shared-with-the-world dept.
stern writes "A security researcher at Cambridge was trying to figure out the password used by somebody who had hacked his Web site. He tried running a dictionary through the encryption hash function; no dice. Then he pasted the hacker's encrypted password into Google, and voila — there was his answer. Conclusion? Use no password that any other human being has ever used, or is ever likely to use, for any purpose. I think."
This discussion has been archived. No new comments can be posted.

Using Google To Crack MD5 Passwords

Comments Filter:
  • Salt (Score:5, Informative)

    by porneL (674499) on Tuesday November 20, 2007 @05:20PM (#21426743) Homepage
    No, the conclusion is you should always use salted hashes.
    • Re:Salt (Score:5, Funny)

      by eln (21727) on Tuesday November 20, 2007 @05:23PM (#21426803) Homepage
      I agree. Also, fry them in bacon fat and add pepper.
    • Re:Salt (Score:4, Interesting)

      by Anonymous Coward on Tuesday November 20, 2007 @05:31PM (#21426917)

      No, the conclusion is you should always use salted hashes.
      I agree, but this isn't something the user can do. I can't register for a site and say, "I need to remember to use salt!" The site has to implement it and implement it correctly.

      The guy posting was posting from the perspective of the user, not the author of the system. The conclusion from the summary is still accurate since you can't make the assumption that salt is always used. The next best defense is a crazy fucking password.
      • Re:Salt (Score:5, Insightful)

        by Em Adespoton (792954) <slashdotonly.1.adespoton@spamgourmet.com> on Tuesday November 20, 2007 @05:55PM (#21427323) Homepage Journal

        agree, but this isn't something the user can do. I can't register for a site and say, "I need to remember to use salt!" The site has to implement it and implement it correctly.

        The guy posting was posting from the perspective of the user, not the author of the system. The conclusion from the summary is still accurate since you can't make the assumption that salt is always used. The next best defense is a crazy fucking password.


        This is why my passwords are themselves salted hashes. The likelihood of someone else using my passwords is the same as a regular hash collision, I get to use a separate password for each place one is required, and the hashing mechanism and salt are simple enough for me to keep in my head. End result: infinite number of easily generatable and retrievable passwords that look just like a hashed password when decoded.
        • Pshaw!

          This is why I all MY passwords are salted hashes that I then re-hash and re-salt. To Taste. ..Check and Mate.
      • The best defense is an active defense, I periodically check my name, my screen names, and my passwords against Google to see it what says. My passwords is in there but not as a password nor in English, but the md5sum isn't, my name is in there and there is an international registry of people with my name, and everything that comes up in my /. user-name is mine except one is a quotation of one of my posting in someones PhD thesis, boy how hard-up is that?
      • by davidsyes (765062)
        Sign those salted hashes in blood. And hope none of your blood or DNA is in someone's possession.

        But, increase the security factor by 10x by adding some spittle to the mix. Add a few strands of hair, an ocular scan, about 2 cubic meters of flatulence as an enhancer, and 3 toenails. Mix well, and syringe feed into the password encryption-generator. Then, put on your jade loin ring. Shoot your transmission and remove your bio-matter from the solid-state password encrypter device. Your password is now secure.
    • by MoFoQ (584566)
      yea, hence even joomla added salting: http://www.joomla.org/content/view/3670/78/ [joomla.org]

      shoot...I love a lil' salt and pepper with my steak.
    • Re:Salt (Score:5, Insightful)

      by Sangui5 (12317) on Tuesday November 20, 2007 @05:58PM (#21427367)
      Rainbow tables? Salting breaks it.
      Precomupted dictionaries? Salting breaks it.
      Brute force and compare against the whole pw list? Salting breaks it.

      Salting is your friend. Long salts don't cost much, but make many attacks completely infeasible. Unix has been using salted passwords since forever. Yet nthash *still* doesn't include a salt.
      • Re:Salt (Score:5, Funny)

        by Anonymous Coward on Tuesday November 20, 2007 @06:28PM (#21427743)
        Ice building up on your sidewalk? Salting breaks it.
      • Re: (Score:3, Interesting)

        by nighty5 (615965)
        You're implying that salting on UNIX makes attacking the hash infeasible, this is simply not true.

        There are only 4096 different combinations in the salting algorithm in crypt() will use which a brute forcer can easily iterate. [regardless of encryption technique md5 or des]

        Salting a known algorithm is almost pointless because as I just described salted passwords can be just as easily defeated if you know the mechanism, this is why NT doesn't include salt. Also salt was used on UNIX only because when shadow
        • Re:Salt (Score:5, Informative)

          by Sangui5 (12317) on Tuesday November 20, 2007 @08:47PM (#21429423)
          You're implying that salting on UNIX makes attacking the hash infeasible, this is simply not true.
          Salting doesn't make breaking hashes infeasible, but it makes the attacker work harder, and makes certain highly efficient attacks infeasible.

          There are only 4096 different combinations in the salting algorithm in crypt() will use which a brute forcer can easily iterate.
          And I completely agree that 12 bits of salt is insufficient in a modern world. Which is why MacOS 10.4 and up uses 32 bits of salt, most Linux implementations use 48 bits of salt, and OpenBSD uses (a rather paranoid) 128 bits. Since it doesn't require any more effort from the user, and only a tiny amount of resources, there's no reason not to use a large salt.

          Salting a known algorithm is almost pointless because as I just described salted passwords can be just as easily defeated if you know the mechanism
          If you have the password hashes they you have the salt too. Either way, brute forcing one password is no harder. But it means you have to work harder to do a whole list of passwords, because each password has to be attacked individually.

          Salting also makes precomputation (pre-built dictionaries and rainbow tables) infeasible. Every bit of salt in essence doubles the amount of storage for your precomputation attack. This is (partly) why a fairly effective set of rainbow tables for LANMAN hashes take only 500ish MB, NTLM hashes take 8.5 GB, but even for the old Unix crypt() it would take at least 2 TB. And don't even think about trying any precomputation attacks against OpenBSD; even if the user was stupid and restricted themselves to 5 digit alphanumeric passwords, your rainbow table would consume more storage than exists. Salting makes you attack each password individually, and keeps you from doing any work ahead of time.

          this is why NT doesn't include salt.
          NTLM doesn't include a salt because (1) MS is trying to maintain a semblance of backwards compatibility with some ill-designed challenge response authentication mechanisms, and (2) they haven't learned the lesson that salting is a valuable strategy to make attacking hashes more difficult.

          Also salt was used on UNIX only because when shadow passwords didn't exist the system had to be protected against users that had the same password and could easily read the password file to compare.
          That is one reason why salts were used for old Unix crypt(). The other was to make precomputed dictionary attacks harder, which is still a valid use. Today, the best reason to use a salted hash is to avoid rainbow tables.

          Really, the modern reason to use a salt is to prevent the type of attack the original poster used, and to prevent rainbow table attacks. Both of these are good attack techniques, and salting completely moots them.
      • by jacrawf (691)
        Part of the reason nthash doesn't include a salt is because MS has an idiotic fondness for challenge-response password protocols which require that actual passwords themselves (or ridiculously weak, non-salted hashes) be stored instead of a strong, salted cryptographic hash of that password. Challenge-response password protocols are completely worthless, and the sooner MS ditches them, the better off they'll be.
      • by ceoyoyo (59147)
        All true, with the caveat that the attacker must be looking to break one of a large number of passwords, and he doesn't care which.

        If he wants to break YOUR password, then salting, at least the common public method, doesn't break any of those. It does break the Google attack though.
        • Re:Salt (Score:4, Informative)

          by Sangui5 (12317) on Tuesday November 20, 2007 @09:01PM (#21429553)
          You are correct that salting does not prevent nor make harder a brute force attack against one password.

          It *does* breaks the Google attack, a precomputed dictionary, and rainbow tables, *even* if the attacker just wants *your* password.

          Of these, rainbow tables is by far the most effective. Nobody computes their own rainbow tables. If I want to attack your hashed password, I'll download or buy a set of rainbow tables. Salting prevents this, because every salt value needs its own set of rainbow tables (or you have to include the salt rainbow table entries, which is approximately the same). Either way, using a 32-bit salt implies that to be equally effective, the total set of tables has to be 4 billion times larger. A 128 bit salt; well, you just can't create a set of rainbow tables for that. It just demolishes their effectiveness.

          As you imply, there is a variant on salting which even makes plain brute forcing harder: don't store all of the salt. Of course this is (1) not widely deployed, and (2) imposes a high cost for legitimate use. Anyway, using repeated hash iterations is better, since you can't parallelize it.
          • by ceoyoyo (59147)
            I said it broke the Google attack. Salting doesn't really break the rainbow table attack, it just makes it more difficult. If your salt is long enough it might break it in practice, and it might make pre-computed tables unusable, but so does not using MD5 as your hash (also breaks the Google approach). You wouldn't say that breaks the rainbow table attack though, it breaks the pre-computed rainbow table attack. From a cryptographic point of view your non-MD5 hash is no more secure against rainbow table
      • by pclminion (145572)

        Rainbow tables? Salting breaks it. Precomupted dictionaries? Salting breaks it. Brute force and compare against the whole pw list? Salting breaks it.

        Salting adds some fixed number of bits of difficulty, it doesn't make anything impossible. In practice, the salt can be made SO large that the multiplier becomes insane (imagine a 12 character password with 1024 characters of cryptographically random salt added to it). But as far as theory goes, salt just makes brute force more work, it doesn't eliminate it

    • by nobodyman (90587) on Tuesday November 20, 2007 @06:50PM (#21428035) Homepage

      No, the conclusion is you should always use salted hashes.
      That's good advice for application developers, but the original post was offering advice to users. Still, even that is a bit of an overreaction. From TFA:

      And indeed, the MD5 hash of "Anthony" was the database entry for the attacker. I had discovered his password.
      Not to diminish this admin's accomplishment (it sounds like he's quite clever), but doesn't this boil down to "don't use your name as your password"? Or better yet, "don't use any proper name as a password".

      Keep in mind that this was a hash of a userid (not a password) that was captured in a google index, and it's highly unlikely that someone will choose a userid on a google-indexed site that just-so-happens to be your 10+ character password that has mixed-case and special characters. I think the same "good password advice" still applies, even in a google-world.
  • by eldavojohn (898314) * <eldavojohn@gm[ ].com ['ail' in gap]> on Tuesday November 20, 2007 @05:21PM (#21426767) Journal
    For those of you who missed it in the article, the has was:

    20f1aeb7819d7858684c898d1e98c1bb
    And sure enough, if you read the comments to the blog, there is a site called http://md5.rednoize.com/ [rednoize.com] that reveals that the hash is "Anthony." So although Google helped, there appears to be resources online for it (if you don't have your own Rainbow Table mega database).

    He could have discovered this if he had used a database complete with names, something I don't think would have been too difficult for him.

    This Google search idea is kind of moot if the user uses some very basic password construction such as what I've commented on before [slashdot.org]. Also, as the blog mentions, this discussion is worthless if WordPress used salting [wikipedia.org] which is related to nonces used in security engineering [wikipedia.org]. I think that stuff has been around for, what about five years now? Wake up WordPress!
    • 5 years? (Score:5, Informative)

      by Junta (36770) on Tuesday November 20, 2007 @05:37PM (#21427019)
      Try decades! The good old days of Unix even had salts (even if they were just two bytes)
    • by HTH NE1 (675604)
      Where was that site in 2002 when people were trying to hack the new TiVo backdoor code [slashdot.org]?
    • by PFAK (524350) * on Tuesday November 20, 2007 @05:53PM (#21427291)
      He can't be much of a "security researcher" if someone hacked his own website.
      • by kbielefe (606566)

        You could put all the security researchers in the world together and they still couldn't tell you all the vulnerabilities that exist in currently deployed software. Perfection is not required to be considered an expert. Now, if this had gone on for a long time, or happened repeatedly, you might have a point.

      • by Cairnarvon (901868) on Tuesday November 20, 2007 @07:03PM (#21428241) Homepage
        He didn't write the WordPress software, and presumably doesn't have the time to audit every bit of code it uses.
        I doubt Bruce Schneier himself audited the entire Movable Type codebase, which he uses for his blog. Does that make Schneier "not much of a security researcher"?
        • by PFAK (524350) *
          I think the primary question is -

          Was his WordPress installation up to date when he was "hacked"?

          If it was not, that would not make him much of a security researcher ..
    • Re: (Score:2, Funny)

      by Anne_Nonymous (313852)
      That's remarkably close to my password hash:

      > Do0d+H!$p@SsW0rD!$t0ta1y$eCuRe
    • Re: (Score:2, Funny)

      by DaFallus (805248)
      And sure enough, if you read the comments to the blog, there is a site called http://md5.rednoize.com/ [rednoize.com] that reveals that the hash is "Anthony." So although Google helped, there appears to be resources online for it (if you don't have your own Rainbow Table mega database).

      Another reverse md5 hash lookup [benramsey.com]

      I have to agree with everyone else so far, pass the Salt.
    • by joNDoty (774185) on Tuesday November 20, 2007 @06:54PM (#21428091)
      Crap. From their "about" page:

      Additionaly everytime when you enter a non-md5 hash string into the search field, the md5 result for that search strings gets stored in our database for future use.
      Thanks for warning me. I tested to see if my password was in there... it is now!!!
    • by ajs (35943)

      This Google search idea is kind of moot if the user uses some very basic password construction
      Step 1: visit (site might be down... service provider issues, grrr)

      Step 2: download the source code

      Step 3: come up with a decent password pattern (e.g. x3-4/x3-4/*/* which means two pseudo-words and two of any characters arranged in any order).

      Step 4: Run the program a few times and pick a password you'll remember.

      Step 5: Profit?

    • Re: (Score:3, Informative)

      by Ossifer (703813)
      md5oogle.com (http://md5oogle.com [md5oogle.com]) is what you want...
  • Obligatory (Score:5, Funny)

    by Anonymous Coward on Tuesday November 20, 2007 @05:22PM (#21426771)
    In Soviet Amerika, MD5 passwords crack you.
  • by morgan_greywolf (835522) on Tuesday November 20, 2007 @05:22PM (#21426787) Homepage Journal
    Most MD5 password hashes, such as those used in *nix, are salted [wikipedia.org], and hence secure from this sort of vulnerability. That Wordpress uses unsalted MD5 sums to store passwords boggles my mind. It shows that the developers know even less about cryptography than I do. That's scary.
    • Or that they are not willing to use the provided password utilities in the HTTP standard. Digest passwords are, at the very least, salted. Oh well, I suppose that if it doesn't "look pretty" people will automatically reject it...
    • by SevenDigitUID (1104081) on Tuesday November 20, 2007 @05:46PM (#21427169)
      That is totally unfair to the wordpress developers. Just because they don't care doesn't mean they don't understand.
    • by cstdenis (1118589) on Tuesday November 20, 2007 @05:48PM (#21427209)
      You do realize that most businesses (and therefore most websites you have accounts on) just store passwords plain text because it's easier to do tech support that way. Salted hashes are better than unsalted hashes, but most don't bother hashing at all.
      • Re: (Score:3, Insightful)

        by LWATCDR (28044)
        I used to store user passwords in plain text on my website. Before anyone gets all bent. I assigned passwords to the users and didn't let them change them. They where AOL style passwords things like blue#guppy. Also there wasn't any personal info that mattered tied to the password. It was a small site and worked well. They couldn't use one password for this simple message base and there bank account, they couldn't use stupid passwords like their first name, and I could look them up if they forget or for tes
      • by xenocide2 (231786)
        Indeed. The purpose of salting and hashing is that they protect the passwords from the administrative staff, and anyone else who can historically see the data.

        What's far more scary is the number of sites that want your email address as a user login. Imagine how many people use the same password across sites, including their email account...
    • by nuzak (959558) on Tuesday November 20, 2007 @05:48PM (#21427211) Journal
      That Wordpress uses unsalted MD5 sums to store passwords boggles my mind. It shows that the developers know even less about cryptography than I do. That's scary.

      Oh it's even better than that. It stores your md5 password in a plain text cookie, and if it receives such a cookie, sets an $already_md5 flag to true that's then passed to wp_login() which then just compares it literally against the unsalted md5 entry.

      <guinness>Brilliant!</guinness>
    • Re: (Score:3, Funny)

      by neoform (551705)
      If you've ever used wordpress before and actually looked at the code, you'll know right away that wordpress inc. does not employ programmers.
    • If you use letters, numbers and a symbol or two then it's not going to be in any database of MD5 hashes.
  • Dark Helmet (Score:5, Funny)

    by Nate Fox (1271) on Tuesday November 20, 2007 @05:24PM (#21426813)
    So the combination is 827ccb0eea8a706c4c34a16891f84e7b. (lifts mask) That's the stupidest combination I've ever heard in my life. That's the kinda thing an idiot would have on his luggage.
  • by GroeFaZ (850443) on Tuesday November 20, 2007 @05:34PM (#21426973)
    The password was hunter2? [bash.org]
  • by owlstead (636356) on Tuesday November 20, 2007 @05:40PM (#21427063)
    But if I ever need to run a hash against a password database, I'll remember this lesson and first perform a Google search. Saves a lot of time and CPU cycles.

    I am already doing this for telephone calls I cannot place. If it's an institution or a person that is calling because of profession, the chances that the telephone is listed somewhere on a (search engine) accessible web page is *very* large.
    • Re: (Score:3, Insightful)

      by CastrTroy (595695)
      I've also started doing this for telephone numbers. Any number I don't recognize, I let the answering machine deal with it. If they don't leave a message, their call isn't important. Also, if you look up the number, just to make sure you didn't miss anything, then you can often find complaint sites when the number belongs to a telemarketer. I think just about every number I've ever looked up that didn't leave a message was a telemarketer.
  • by russ1337 (938915) on Tuesday November 20, 2007 @05:45PM (#21427145)
    5f4dcc3b5aa765d61d8327deb882cf99 is the MD5 hash for 'password'.....

    search enough systems and you're bound to see some doosh has used it.
  • by this great guy (922511) on Tuesday November 20, 2007 @05:58PM (#21427371)

    I have personally been using Google this way for a while. This is the first thing I do when I encounter a passwd hash during a pentest. This is a technique that works very well especially for hashes produced by random apps that you have no idea what hashing algorithm they use. It works well not because the public passwd hash databases indexed by Google are large (they are not), but because they are very diverse, both in term of number of algorithms (MD5(), MD5(uppercase()), SHA1(), etc) and in terms of number of hash formats (hexadecimal value, decimal value, base64, etc).

    And above all, it only takes 2 sec to perform the Google search.

    • by fo0bar (261207)

      I have personally been using Google this way for a while. This is the first thing I do when I encounter a passwd hash during a pentest.


      Do you then let your clients know that you've sent sensitive company information to a commercial third party using insecure channels?
  • on a related note... (Score:5, Interesting)

    by sootman (158191) on Tuesday November 20, 2007 @06:07PM (#21427473) Homepage Journal
    ... I wish Google would collect/show/use checksums of files in search results. It would be a great way to find identical files.* Thousands of uses:
    • I found this file on my computer and I forgot where it came from.
    • I downloaded this file but I forget where I got it. It's too big to email so I would like to send a friend a link to the original file.
    • I want to see if anyone has taken this pic from my site and posted it elsewhere.
    • This download is taking FOREVER. Is anyone else hosting this exact file?
    and many, many more. I had this idea years ago and sent it in to them but haven't heard anything since. I don't want any credit**, just implement it and let me know when it's up and running! And the funny thing is, I'm sure Google is already checksumming every file as part of how they do all their magic. All they have to do is post the data!

    * and, since collisions are possible, it would provide a nice corpus to study collisions, etc. in the real world.

    ** this isn't an entirely original idea. Linux distros have been posting checksums for years as a way to let users verify that their downloads were not corrupted; as a bonus, I (and I'm sure some others) have done searches of those values to find sites hosting that particular release.
    • A similar idea is to use a hash tree (Merkle tree) and build a hash of small blocks of data. That way, you can see whether multiple files share common blocks of data and also automatically implement P2P or caches for transfers of large files with automatic hashing of the entire file (for ease of referencing) and individual blocks during a transfer. Gnutella uses Tiger trees for this, but it would be nice if there was an official standard URI format for hash trees so that Google and other search engines coul
    • by J0nne (924579)
      Every p2p network worth using can be used for this. You can even fix corrupt files this way, if you know the original hash and someone on the network has a copy of the file. Examples of this system are magnet links, ed2k links, metalinks and even torrents.
    • by pclminion (145572)

      An MD5 hash is a pseudo-unique identifier of a piece of data based on its contents. Everything you've said is exactly the entire PURPOSE of a hash function. Boil down a piece of data to some fixed size code, and use this to index things. MD5, on top of being a hash, is a SECURE hash (well, relative term).

      I don't want any credit**, just implement it and let me know when it's up and running!

      Thank God you don't want credit, because nobody is going to give you any for coming up with something [wikipedia.org] that's been

  • by fo0bar (261207) on Tuesday November 20, 2007 @06:11PM (#21427527)
    Results 1 - 10 of about 101,000 for d41d8cd98f00b204e9800998ecf8427e. (0.04 seconds)
  • I know of efforts in this regard that date back 3 years or so, although I'm not aware of whether these projects are still online. There are some good discussions about the idea at http://ibneko.livejournal.com/668715.html [livejournal.com] and http://www.dragoslungu.com/2007/06/22/google-md5-hash-search-engine/ [dragoslungu.com]. My interest is that I'm attempting to get Google to index such hashes at http://www.nth-dimension.org.uk/utils/ghash.php [nth-dimension.org.uk]. In my case I'm actually attempting to get Google to cache my hashes to minimise my storage
  • Credibility? (Score:3, Informative)

    by MarkLewis (593646) on Tuesday November 20, 2007 @06:32PM (#21427811)
    Am I the only one who thinks that a "security researcher" whose site gets hacked and is about as credible as an accountant who fails an audit?

    And for his sake I really hope that he knew about rainbow tables and just decided for some indecipherable reason not to mention that they are far more effective for password cracking than Google searches.

    And who submitted this story to Slashdot with the sensational summary about "any password used by anybody, ever" being vulnerable to Google searches? That's an easy enough claim to completely debunk by taking MD5 hashes of several passwords and sampling which ones come back. Let's see:

    92259762923b4e79d2073ecb03217462 (hash for 'july2007') - Nothing
    6e933f3054f533c63dd59479ca9f4b6f (hash for 'hello_world') - Nothing
    2c6c8ab6ba8b9c98a1939450eb4089ed (hash for 'abc123') - Google found this one as an md5 example
    6a51f1fe97bdebece7652842a0e2351e (hash for 'pickles') - Nothing
    5eaaf94141c371ce96675aa6445003c4 (hash for 'happy') - Nothing

    So basically not even common words get picked up by Google, much less "any password used by anybody else, ever".
    • Re: (Score:2, Funny)

      by garompeta (1068578)
      With all my respect, 596a96cc7bf9108cd896f33c44aedc8a
    • Re:Credibility? (Score:4, Informative)

      by dgym (584252) on Tuesday November 20, 2007 @07:10PM (#21428315)
      Your strings have newlines in them, maybe you meant:
      echo -n happy | md5sum

      most password fields don't accept newlines, so trying without them:
      3e652df0f1332cfc9df779d49667defc - still nothing
      99b1ff8f11781541f7f89f9bd41c4a17 - still nothing
      e99a18c428cb38d5f260853678922e03 - abc123
      fd03204cfdc557b0f0d134773ae6fff5 - obscure, it finds a flash app on a site called pickles and things
      56ab24c15b72a457069c5ea42fcfc640 - happy

      So it is still not that much of a problem, but at least happy is on the list.
      I wonder if negative outlook words are more or less secure?
    • Perhaps he has better things to do than audit the complete WordPress codebase?
      If he'd written his own software, you might have half a point (though only half of one; perfectly secure apps, especially perfectly secure web apps, are always a pipe dream).
      If he'd been a victim of the same exploit several times in a row, then you might have a full point.

      You can't blame a person for being a victim of a zero-day exploit in someone else's software, especially if the software is as complex as a blogging/CMS platform
    • Now try it with several hundred passwords. Based on the results of Alec Moffett's old Crack program for DES, I'd suspect that you'd find roughly 10% of all passwords quite easily, with "love" leading the list.
    • by pvera (250260)
      My knee-jerk reaction was to search for hello (b1946ac92492d2347c6235b4d2611184) and yes, I did get results. It was the only one I could find thru Google.
    • by neonsignal (890658) on Tuesday November 20, 2007 @08:15PM (#21429099)
      I looked these up on google, and they directed me to some slashdot page...
  • by Antique Geekmeister (740220) on Tuesday November 20, 2007 @07:29PM (#21428537)
    It's no worse than Subversion's insistence on storing user passwords for any protocol but SSH public keys in a local plaintext file.

    Do not *EVER* allow a Subversion system to use the same passwords as the user system, and if you have access to the user's accounts, run a check of their stored Subversion passwords to make sure they didn't use their same password somewhere else as for their local user account.
    • by chochos (700687)
      Subversion on Mac uses the Keychain to store the passwords instead of the local file. At least since 1.2 I think. Or are you referring to the server?
  • Google is now shutting down servers and re-routing as they try and halt the spread of the newly-detected worm that tries to do a DOS on google, by making affected machines do a google search with random strings that look like 0cfa9f600839f57e90e5559b8ee54864

    But seriously, as fun as it is to look up all your hashed responses on google, I'm going back to por... work :)

    You might also want to check out http://utilitymill.com/utility/Goog_Your_Hash [utilitymill.com] to see if your password is 'safe'.
  • No, it means that as the attacker, security through obscurity is not only advantageous but should be highly encouraged. It doesn't work when designing security, but it's quite effective in conjunction with other basic protections when used in limited cases for nefarious means. For instance, you know where to find resources on MD5, SHA-1, et cetera but do you know where to find resources about WQEWERSDF (the crappy but effective and thoroughly obfuscated hashing method i just made up)?

    Consider that with the
  • Like GData [gdataonline.com]. That has been around since the summer of 2005.
  • I suppose about anything gets logged nowadays.

    I like to search for a part of my password on my computer every once in a while to see if programs store in plain text.

    If my password would be "zxcvbbn.34#$" then I would search for "vbbn".

    So for google; you can search for a part of your hash but still be secure.
  • by pestilence669 (823950) on Wednesday November 21, 2007 @02:28AM (#21431991)
    You can use the standard HMAC algorithm on top of MD5 or SHA1 to adequately hash a password. It's much better than simply appending or prepending garbage to your cleartext.

    PHP5 has a function built-in and I'm sure most other languages have comparable implementations available. It's not fool proof by any stretch, but if you use a randomly generated fixed "key," it at least prevents someone from using Google to discover the cleartext.

    Better still: Use a unique value for the account + a randomly generated key. For example:
        Key = "c,.rcph203p9h"
        UserID = 12
        HMAC_KEY = "c,.rcph203p9h::12"

    That will make it computationally difficult to crack, as each password must be brute-forced individually.

Every successful person has had failures but repeated failure is no guarantee of eventual success.

Working...