Slashdot Mirror
Using Google To Crack MD5 Passwords
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."
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.
Use a crazy fucking password, but you don't have to remember all of it.
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.
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.
If you don't have to remember part of it, why not make the whole password fucking crazy? Since you already have to cut'n'paste, why have a part of the password be easier than another?
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 testing.
When I moved to a CMS we went to hashed passwords.
Boy is it a pain. Nobody understands that even I can not look at their passwords. Yes a salted hash is the correct and secure way to do things... But it can be a pain in the rear.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
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"?
The Tao of math: The numbers you can count are not the real numbers.
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.
There are programs such as MyPasswordSafe, that allow you to store your passwords in an encrypted form. I have one crazy password that protects all the other passwords. I haven't checked the encryption on it, but I know I need the password (which is stored only in my head), to unlock the other passwords.
This is slashdot, we need a bad car analogy too. :P
You don't realize how many developers have no clue what a salted hash is and how it works. I've had discussion with developers who weren't complete morons when it comes to programming that had no fscking idea what I was talking about. They fully knew what a hash was, but it was unconceivable that you could store a salt value next to a hash. They were massively deniyng that it could work, trying to make fun of me "it's impossible, that's not how cryptographic hashes work" etc.
On a related side not you'd be amazed at the number of developer that have no fscking clue about how public key cryptosystems works.