Slashdot Mirror

← Back to Stories (view on slashdot.org)

Using Google To Crack MD5 Passwords

Posted by kdawson on 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."

8 of 232 comments (clear)

  1. In itself nothing new by owlstead · · Score: 4, Insightful

    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.

  2. Re:Salt by Anonymous+brave+dude · · Score: 3, Insightful

    Use a crazy fucking password, but you don't have to remember all of it.

  3. Re:Salt by Em+Adespoton · · Score: 4, Insightful

    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.
  4. Re:Salt by Sangui5 · · Score: 4, Insightful

    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.

  5. How about "don't use your first name As your PW"? by nobodyman · · Score: 3, Insightful

    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.
  6. Re:MD5 Lookup Site & Names by Cairnarvon · · Score: 5, Insightful

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

  7. Re:french bitch by maxwell+demon · · Score: 4, Insightful

    I just hate douche bags who can't spell. Spelling errors can make your password more secure!
    --
    The Tao of math: The numbers you can count are not the real numbers.
  8. No worse than Subversion by Antique+Geekmeister · · Score: 3, Insightful

    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.