Slashdot Log In
Using Google To Crack MD5 Passwords
Posted by
kdawson
on Tuesday November 20, @04:19PM
from the secrets-shared-with-the-world dept.
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."
Related Stories
Using Google To Crack MD5 Passwords
|
Log In/Create an Account
| Top
| 232 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Salt (Score:5, Informative)
(http://pornel.net/)
Re:Salt (Score:5, Funny)
Re:Salt (Score:5, Funny)
(http://slashdot.org/~eldavojohn/ | Last Journal: Thursday November 15, @01:07PM)
Re:RTFA (Score:5, Funny)
Re:Salt (Score:4, Interesting)
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:4, Funny)
Re:Salt (Score:4, Informative)
Re:Salt.. .so then develop (Score:5, Funny)
(http://www.otanashide.com/ | Last Journal: Monday November 26, @08:56PM)
Crazy fucking luser. Crazy fucking assword. Crazy fuckin' whirled up world.
The above is the 1.0 tourettes pack, silver. Stainless-fucking-steel adds an additional language pack...
Re:Salt (Score:4, Informative)
(http://www.networkboy.net/)
That adds a "local salt" but... courtesy of possible hash collisions there is another password that may work equally well.
by having the login function add the salt a straight rainbow lookup is defeated (unless you pre-computed a rainbow with the salt). As admin he could still enter the salted MD5, find a suitable password without salt, disable salting, get in enable salting, change the password. BUT a "normal" hacker without access to the DB tools and salting function of the app, but in possession of the hash table (and even the salt to some extent) would be defeated. if the attacker had the salt and hash table then with enough time the will break you login through rainbow tables, but not before.
-nB
Re:Salt (Score:4, Informative)
(http://www.intelligentblogger.com/ | Last Journal: Monday August 27, @11:47AM)
http://passwordmaker.sourceforge.net/passwordmaker.html [sourceforge.net]
One password for all sites, but a unqiue, "fscking crazy" password for all of them. You're welcome.
Re:Salt (Score:5, Insightful)
(http://emulation.victoly.com/ | Last Journal: Thursday November 30 2006, @06:03PM)
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.
Re:Salt (Score:5, Insightful)
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)
Re:Salt (Score:5, Funny)
(Last Journal: Wednesday October 24, @11:51AM)
Need something else to put on those fries? Salt it!
Need to make your friend's drink taste awful? Salt is the way to go.
(Somewhere along the line we left the analogy department
Re:Salt (Score:5, Funny)
(Last Journal: Wednesday August 14 2002, @12:33PM)
Re:Salt (Score:5, Funny)
(http://milosmusings.blogspot.com/)
Before the cream sits out too long, you must salt it.
When something's going wrong, you must salt it.
Now salt it! Salt it good!
Re:Salt (Score:5, Informative)
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.
Re:Salt (Score:4, Informative)
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.
How about "don't use your first name As your PW"? (Score:4, Insightful)
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.
MD5 Lookup Site & Names (Score:5, Informative)
(http://slashdot.org/~eldavojohn/ | Last Journal: Thursday November 15, @01:07PM)
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)
Re:MD5 Lookup Site & Names (Score:4, Funny)
Re:MD5 Lookup Site & Names (Score:5, Insightful)
(http://cairnarvon.rotahall.org/)
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"?
Re:MD5 Lookup Site & Names (Score:5, Funny)
Obligatory (Score:5, Funny)
Re:Obligatory (Score:5, Funny)
(Last Journal: Sunday November 06 2005, @10:30PM)
My uneducated respose would be: (Score:4, Funny)
(http://shorl.com/mabrotabrapregi | Last Journal: Friday November 01 2002, @03:39PM)
I wouldn't be too alarmed. (Score:5, Informative)
(http://stylus-toolbox.sf.net/ | Last Journal: Tuesday May 15 2007, @11:50AM)
Re:I wouldn't be too alarmed. (Score:5, Funny)
Re:I wouldn't be too alarmed. (Score:5, Interesting)
Re:I wouldn't be too alarmed. (Score:5, Interesting)
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>
Dark Helmet (Score:5, Funny)
Let me guess (Score:5, Funny)
Re:Let me guess (Score:5, Funny)
(http://thrdcross.com/)
Salt (Score:1, Redundant)
In itself nothing new (Score:5, Insightful)
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.
just look for "cf99" (Score:3, Funny)
search enough systems and you're bound to see some doosh has used it.
Re:french bitch (Score:4, Insightful)
(Last Journal: Wednesday August 14 2002, @12:33PM)
Great job.. (Score:1)
Do I also get a slashdot story if I crack a SHA1 hash with google?
Found my password (Score:1)
Sorry... (Score:1)
Been there. Done that. (Score:4, Informative)
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.
on a related note... (Score:5, Interesting)
(Last Journal: Thursday July 12, @12:30PM)
- 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.
Man, I need to change my password NOW. (Score:5, Funny)
Google indexed already (Score:1)
Google Hash (Score:2)
(http://www.machine.org.uk/)
Credibility? (Score:3, Informative)
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:Credibility? (Score:4, Informative)
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?
Re:Credibility? (Score:5, Funny)
No worse than Subversion (Score:4, Insightful)
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.
My Hash (Score:1)
(about:mozilla)
new worm spreading (Score:2, Interesting)
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... (Score:2)
Consider that with the fact that the vast majority of everybody, but especially incident responders, sysadmins, et al can barely read strace output, must less reverse my backdoor, regardless of whether i pack it full of fun for the RCE or not.
Hash DBs have been around for years. (Score:2, Informative)
Finding your hashes on google (Score:2)
(http://tribbin.nl/)
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.
Hold the pepper... (Score:1)
HMAC (Score:3)
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.
Salt it (Score:2, Funny)
I pepper my hash... (Score:1)
(http://www.ie-ap.org/ | Last Journal: Tuesday March 28 2006, @05:27AM)
I want to thank you all... (Score:1)
Thanks again!!
Make the hashing inefficient (Score:1)
on salted hashes... (Score:1, Insightful)
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.
Reverse MD5 in multiple databases (Score:1)
Re:Don't panic! (Score:2, Informative)