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

Comments

Salt

[porneL]

No, the conclusion is you should always use salted hashes.

Re:Salt

[eln]

I agree. Also, fry them in bacon fat and add pepper.

Re:Salt

[Anonymous Coward]

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

[MoFoQ]

yea, hence even joomla added salting: http://www.joomla.org/content/view/3670/78/

shoot...I love a lil' salt and pepper with my steak.

Re:Salt

[eldavojohn]

And blackjack ... and hookers. In fact, forget the hashes!

Re:Salt

[Anonymous brave dude]

this isn't something the user can do

That's not true. The user can generate a string with something like dd if=/dev/urandom bs=21 count=1|openssl base64 , store that string, and append it the the true password each time the log in. This has exactly the same results as the site correctly implementing salting.

Re:Salt

[SevenDigitUID]

That's not true. The user can generate a string with something like dd if=/dev/urandom bs=21 count=1|openssl base64 , store that string, and append it the the true password each time the log in. This has exactly the same results as the site correctly implementing salting. So what you are saying is the best defense is to use a crazy fucking password?

Re:Salt

[SevenDigitUID]

No, the conclusion is not to use the same password on different sites. Never trust that the software package properly safeguards your password from the administrator. This may be poor crypto, but in many cases, software packages just don't bother to encrypt the password at all. I've seen several websites that store password in plaintext or rot13 (actually it was ROT3).

Re:Salt

[Anonymous brave dude]

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

Re:Salt

[Em Adespoton]

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.

Re:Salt

[Sangui5]

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

[networkBoy]

Not entirely.
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

[repvik]

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?

Re:Salt

[Anonymous Coward]

Ice building up on your sidewalk? Salting breaks it.

Re:Salt

[AKAImBatman]

Better solution:

http://passwordmaker.sourceforge.net/passwordmaker.html

One password for all sites, but a unqiue, "fscking crazy" password for all of them. You're welcome.

Re:Salt

[Jarjarthejedi]

Pretzels missing that unique flail? Salting solves it!
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 :P)

Re:Salt

[Garridan]

Because if somebody gets that file, they've got your password. This way, they'll have to hack your brain, as well as your computer, to get at your password.

Re:Salt

[Wrangler]

Yes, be sure to cut and paste your password hash from your account on your server at your IP address into Google so that Google will have it indexed by the time I search for it. That is, of course, unless Google (or whoever figures out how to MOM/PHISH the Google site first) stores that combination of password hash (almost certainly brute forced by now), userid, and IP address in their burgeoning catalog of "systems that are owned thanks to stupid user tricks published in /."

Passing out passwords, in any format, is D-U-M dumb!

=:^)

Re:Salt

[nighty5]

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 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.

Re:Salt

[jacrawf]

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.

Re:Salt

[Stewie241]

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.

Re:Salt

[CarAnalogy]

This is slashdot, we need a bad car analogy too. :P

Re:Salt

[maxwell demon]

This is slashdot, we need a bad car analogy too. :P Your car rusting too slowly? Salt solves that! :-)

Re:Salt

[csteinle]

When a problem comes along, you must salt it.
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

[ceoyoyo]

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

[Sangui5]

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.

Re:Salt

[Sangui5]

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.

Re:Salt

[pclminion]

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 as an attack.

Re:Salt

[ceoyoyo]

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 attack than is your MD5 hash.

Salting doesn't have any effect on dictionary attacks against a small number of passwords unless you keep the salt secret. But then you're really doing a kind of secret key encryption, with all it's inherent problems, and you might as well just use an algorithm specifically designed for it.

Re:Salt

[budgenator]

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?

Re:Salt

[davidsyes]

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.

Re:Salt

[that this is not und]

Salting broke our front stoop. Well, I don't know for sure that it was salt, but that chemical dissolved away some of the cement.

Re:Salt

[benplaut]

Is that problem, by chance, a slug?

Re:Salt

[VGPowerlord]

Then again, if he already has access to disable salting, he doesn't really need a password, does he?

Re:Salt

[jibjibjib]

And remember that safeguarding a password from the administrator is ineffective anyway, because all the administrator has to do is wait until the next time you log in, and sniff your password then.

Re:Salt

[jonadab]

> 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.

If it costs so little and has so much value, why does OpenBSD use such a piddling amount? 128 bits? Given the size of modern computer storage (both primary and secondary) and processing power, why not just use a couple dozen kilobytes of salt and have done? I mean, sure, it's overkill, but the nice thing about a good solid healthy dose of overkill is, you can stop worrying about whether it's really _enough_, and whether advances in technology in a couple of years might cause you to need to upgrade it. Why use 2-4 times as much salt as the competition, when you can just as easily use several *hundred* times as much?

(My guess at the answer is that there really *is* a cost to using more salt, so OpenBSD stops at 128 bits because they figure it's *enough*, and more would degrade performace or incur some other cost. But that's just a guess.)

On the other hand, I tend to think salt is mostly important because people use such weak passwords. If people would just stop trying to scrimp a couple of keystrokes and finally break down and use nice long 30+ character passwords, it would make brute-force attacks a *LOT* harder. For stuff where security actually matters, I tend to think sentence-length passwords are entirely reasonable.

ISTR a User Friendly strip where Erwin set some dude's password to ampersandforwardslashforwardslash rightsquarebrackethyphencapitalAsemicolonsemicolon. (Okay, so it's more likely that Erwin actually meant that he set it to &//]-A;;, but the spelled-out version is more spectacular, IMO.)

Of course, you still have to worry about your passwords being discovered via surveillance, social engineering, or good old rubber hose cryptanalysis...

Re:Salt

[TheLink]

"Challenge-response password protocols are completely worthless, and the sooner MS ditches them, the better off they'll be."

Tell that to the WiFi standards people. http://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#PEAPv0.2FEAP-MSCHAPv2

Seems almost as if the WiFi people were bribed to make stuff that in practice will have crappy security (too difficult to secure).

Re:Salt

[Anonymous Coward]

Ah, the loin ring has to be *jade*. That's what I keep forgetting.

Re:Salt

[jacrawf]

Just another reason to not rely on that crap and instead opt for judicious use of crypto at layer 3 wherever possible. Having your router only accept DHCP and IPSec traffic is a pretty good start if you're paranoid. Just turning off SSID broadcasting seems good enough if all you want is to keep out the neighbors, though.

Re:Salt

[Anonymous Coward]

braaiiins...

Re:Salt

[Anonymous Coward]

Wouldnt work --
md5 38106c4335597850487fcf3c3becb277 -> "crazy fucking password"

Re:Salt

[Anonymous Coward]

Butthash!

Re:Salt

[jamesshuang]

I'm currently designing a webmail system similar to squirrelmail (because it's ancient and I hate the second login, separate from my site). I would love to use salted hashes in my database, but unfortunately doing so would require that the user enter their password again when they go into the email portion of the site, or even worse, force me to store their password in plaintext in cookies on their computer. Is there a good way around this? I know that the php imap functions require the plaintext password for the email account to work...

Re:Salt

[PReDiToR]

Or you could use Password Hasher for Firefox?

Re:Salt

[nmg196]

How can a website *user* use a salted hash? They can't!

The original suggestion to use a totally unique password is the correct answer.

Personally, I always use a GUID for my password and I use a different one for each site :) </lie>

Re:Salt

[emj]

So lets say you go to South America on a weekend trip and you want to post some pictures on Flickr.. Howto access those password?

braiiins...

Re:Salt

[MrAngryForNoReason]

So lets say you go to South America on a weekend trip and you want to post some pictures on Flickr.. Howto access those password?

You can store Password Safe on a USB flash drive and take it with you to South America, plug it in, run Password Safe from the USB drive and access your passwords.

This would also protect you against keyloggers on a public machine as Password Safe will fill passwords in for you meaning you don't need to actually type it.

Re:Salt

[joke_dst]

You're assuming there is a plaintext password in the rainbow table that matches the hash. This is very unlikely.

Rainbow tables doesn't contain a password for EVERY possible hash, only common and short passwords are usually included.

Re:Salt

[Anonymous Coward]

don't forget to stir, and if you have to poke, use your finger but wash before poking again, it might spoil the goods...

Re:Salt

[ArsenneLupin]

Pretzels missing that unique flail? Salting solves it! Crazy madman bombing your country/taking away your freedoms? Pretzels solve it!

Re:Salt

[Atti K.]

KeePass Password Safe is even better. There's also a Linux and OS X port.

Re:Salt

[Drysh]

You can salt your own password.. To some degree at least.. Nobody can remember different crazy passwords for every site they sign, but you can create a personal algorithm for your passwords. I use this: my general password + site name. Suppose my standard password is money, my password for slashdot would be:
moneyslashdot

Re:Salt

[Anonymous Coward]

Without the silly people this world would be a very dull place :-D

Re:Salt

[rufty_tufty]

The main reason to not use sentence length passwords is _stupid_ yet common password strength checkers do a dictionary check.

e.g. sd%$yhIQ is apparently a better password than sd%$yhIQSilly_Stuff_ouT_of_the_wAy. Anyone who thinks this is the case - like just about every password strength checker I have ever come across - should be shot.

Which to me is nuts!
Also older unixs ignore anything longer than an 8 character password, you are free to have a longer one, thay'll just let you in regardless of what you type for character 9+. It's been about 3 years since I cam across one of these, but I'm sure lots of company password schemes are based around the lowest common denominator.

Re:Salt

[cxreg]

Also older unixs ignore anything longer than an 8 character password, you are free to have a longer one, thay'll just let you in regardless of what you type for character 9+. It's been about 3 years since I cam across one of these, but I'm sure lots of company password schemes are based around the lowest common denominator.

This is how DES crypt works. Upgrading to MD5 passwords is one way of fixing that problem.

Re:Salt

[networkBoy]

As google's index grows the ability to build a complete MD5 or SHA1 rainbow table from several pieces grows.
[tinfoil_hat]
the NSA's rainbow tables are already hash complete.
[/tinfoil_hat]
-nB

Re:Salt

[guardian-ct]

You type your screen names and passwords in to Google in order to check them? That's not security that I'd recommend to anyone. You may have also told a whole bunch of people that your password isn't in English, but is probably a word in some other language.

Are you sure that active "defense" is the correct word to use?

Re:Salt

[budgenator]

I used to get all the email addressed to qwerty@poiuyt.com, now that was interesting, I'd get "lost" passwords for every site imaginable.

Re:Salt

[petermgreen]

I very much doubt anyone has a table of a corresponding input for every MD5 has.

there are 2^128 md5 hashes, if we assume we have to allow 32 bytes for each input (twice the length of the output seems like a reasonable starting point for space to allow) then that means such a table would be 2^128*32=2^133 bytes.

the largest readilly availible hard drives are about 2^40 bytes.

so to store your MD5 reversing table you would need about 2^93 hard drives.

using the approximation that 2^30 ~= 10^9 (yeah I know it's not very accurate but it will get us within an order of magnitude which is more than good enough to prove my point) that is about 8 billion billion billion hard drives.

Re:Salt

[Anonymous Coward]

>No, the conclusion is you should always use salted hashes.

Salt, indeed, solves this problem. Like so many others!

Disclaimer: I work at a salt plant.

Re:Salt

[jonadab]

> The main reason to not use sentence length passwords is _stupid_ yet common
> password strength checkers do a dictionary check.

Okay, but if you know how to do your own strength calculations, why listen to what a flawed password strength checker is telling you? As I've noted before, a typical dictionary (e.g., /usr/dict/words on my FreeBSD system) has a couple hundred thousand words in it, so stringing four arbitrary words together, assuming that the attacker knows you generated your passwords in this fashion, would take significantly longer to brute-force than a traditional eight-character mixed-alphanumeric mess (in fact, about as long as a _twelve_ character mixed-case alphanumeric mess), despite also being rather easier to remember. If you throw in a word that's unlikely to be in most dictionaries (common proper nouns don't count here; cracker dictionaries include them, for obvious reasons), then it's even stronger. Even quite minor mangling makes it even stronger.

Personally I like to make up my own pseudowords to throw into the mix for one of the words, resulting in something along these lines...
forsakenly-namblifuzined-apolysis-toad
arecaine-amoretto-became-malapulchrated
gnophlichootsie-ninth-woodpeck-astern

It's difficult to exactly calculate the strength of those, but without question they are significantly stronger than the all-dictionary-words equivalent, and not very much harder to remember. Rainbow tables, in conjunction with distributed computing (using e.g., a botnet) would help (assuming the tables were constructed based on some knowledge of the password structure, e.g., assuming it uses dictionary words and is long), but assuming your system uses reasonable key strengthening measures (e.g., salt), that's only going to get an attacker so far.

And, of course, if a naive attacker tries to use the simple approach (try all single chars, then all permutations of two chars, then three, and so on), then they aren't going to get to passwords that long within your lifetime, and rainbow tables would probably not help much even _without_ strengthening measures.

This all assumes you're defending against remote attackers who can't do on-site surveillance. Otherwise you have to deal with possibilities like a hidden camera watching you type the password. It also assumes the user isn't going to install a trojan that comes with a keystroke sniffer, or give the password out over the phone in response to some kind of social engineering ("Hi, I'm calling from Gartner, and we're conducting a survey of information security practices, especially as regards typical password strength...") or cetera.

Re:Salt

[jonadab]

> Also older unixs ignore anything longer than an 8 character password, you are free to have a
> longer one, thay'll just let you in regardless of what you type for character 9+.

How old is "older" in this context?

Because that's an extremely bad design, with a terrible failure mode. Hard limits on password length are Very Bad, but _silent_ limits on the _effective_ length are much, much worse. I have a hard time imagining that any such systems would still be in widespread use (on public-facing systems anyway) by now, with 15+ years under our belts of hard lessons about the sheer size and chaos that is the public internet.

Re:Salt

[Anonymous Coward]

Why use 2-4 times as much salt as the competition, when you can just as easily use several *hundred* times as much?

Because you'll have a heart attack.

Re:Salt

[Antique Geekmeister]

Do any of you remember Alec Moffett's "crack" program? It would pre-scan large tables of likely passwords, and pre-generate the encrypted passwords, *with the salts* to compare against the encrypted password table. The first few passes would catch nearly 10% of most passwords on a large site.

Doing this kind of scanning is similar: salting helps reduce the likelihood of previous publication by quite a bit, but it only takes a publication of a "crack" style table of popular passwords to threaten a noticeable percentage of your site's passwords.

Re:Salt

[rufty_tufty]

I pay attention to it simply because it is the system dictated by work and it won't allow you to use the password if it thinks it is a bad one - the above example is a genuine one that I wanted to use a longer more secure password and couldn't because it forbid me and rejected it.

Re:Salt

[rufty_tufty]

The most recent one was a sun computer I was using in 2005 - I believe it was a recent (at the time) install too. The whole problem was one of backwards compatibility - they had to maintain backwards compatibility with the existing password system which could probably trace its roots back to the 70s. It may even be the case that this is still true - but have no idea how to prove it since all my current servers are linux based :-)

Re:Salt

[zerkon]

Only problem with that is occasionally there's a vulnerability in firefox. I prefer KeePass for that reason. It sits nicely on a USB flash drive, it's open source (and significantly smaller than firefox if you actually wanted to go through the code), and it uses good encryption (AES/Twofish). It's really a nice little app

Re:Salt

[PReDiToR]

I have used that for years; as you say, a great app for keeping on something like this.

Of course, this would be an even better idea if it had BlueTooth inside too, but that is just a pipe-dream.

Re:Salt

[Sangui5]

For OpenBSD specifically, well, they use a variant on blowfish for their hashing, called eksblowfish (for expensive key schedule). The key setup portion is purposefully slow; this severely limits speed of brute forcing attempts. Further, they use the salt in the key setup phase, which limits precomputation in the key schedule portion. Due the specific choices they made in designing eksblowfish, they need exactly 128 bits of salt, no more no less. Also, they are limited to 55 character passwords. Changing this limitation would require fundamental changes to the underlying blowfish algorithm, and is hence difficult to do. Essentially, they traded off the eks portion of their password hash (which makes it slow to brute force and resistant to future technological advances) for flexibility in password length and salt length. A paper detailing OpenBSDs password hashing is available from Usenix at http://www.usenix.org/events/usenix99/provos.html for free.

(As an aside, they could have done better. Of course, it is easy to say that after the fact, given people have had years to think about eksblowfish; they were then and still are now just about the best password hashing scheme one could concoct. A slight strengthening would be to use a good hash function (e.g. SHA-512) to pre-hash the password, then truncate that for use as the "password" in eksblowfish. This would allow arbitrarily long passwords, although it wouldn't allow more than 512 bits of entropy in the password, or any more entropy than eksblowfish currently takes)

For other hashing schemes, there is no point in using more salt than the size of your password hash. If your hash is only 128 bits (as is MD5), then for every salt longer than 128 bits, there is a shorter salt which collides with it. Since the real threats are dictionary and rainbow table, and attackers can take advantage of collisions, you cannot use salting to make the problem any harder than your hash length. There is a cost to longer password hashes, although it is relatively minor (and, per the argument of the OpenBSD crowd, you *ought* have an expensive hash).

On the other hand, even 64 bits of salt is quite paranoid anyway; it makes a dictionary attack a bit over 18 billion billion times harder. 128 bits is overkill already. Extreme overkill. It is far easier to just brute force the password (which salting doesn't help) than to use any precomptutation at that point. The average password has very few bits of entropy; this is a fundamental limit of passwords. It is hard to remember things with high entropy. Even long sentences don't have that much entropy, because sentences have a lot of predictability in them. Remembering enough to make Linux's 48 bit salts the weak link is pretty much impossible for your average user, and requires a special effort even for people who care.

Re:Salt

[jonadab]

> Changing this limitation would require fundamental changes to the underlying
> blowfish algorithm, and is hence difficult to do

Ah. That makes sense, and is a good reason. In cryptography, a known algorithm that has been examined in some depth and whose strength is considered a known quantity is almost always preferable to a new algorithm of unknown and untested strength. Of course vulnerabilities (e.g., to deliberate collision generation) are from time to time discovered even in long-established algorithms, but even then usually the dammage is of a relatively mild nature, e.g., the sort of thing that potentially cuts average compromise time in half or so, as opposed to the sort of thing that reduces it a thousand fold. With a new algorithm that has not been investigated in detail by the security community, you have no idea what weakness somebody's going to uncover next week.

> As an aside, they could have done better.

Of course. That's always the case.

> For other hashing schemes, there is no point in using more salt than the size of your password hash.

Okay, but in general, I would argue that...

> (and, per the argument of the OpenBSD crowd, you *ought* have an expensive hash)

Exactly. As I was saying, I would argue that in general it is extremely worthwhile, from a security perspective, to have a hash that's longer and more expensive than you think is actually necessary.

Among other things, weaknesses *are* discovered from time to time in the known algorithms (both the hashing algorithm itself and also other related algorithms, e.g. for encryption, which is used in conjunction with hashing), and while for established algorithms these are seldom fatal, they nevertheless sometimes result in an overall reduction in security. If you're significantly more secure in the first place than you thought you needed to be, this hurts less.

Also, backward compatability concerns occasionally result in something being used *well* past the end of its original projected lifespan, and with advances in processing power (and storage, and networking, and so forth) this has significant implications for security. If you think something will *probably* be used for ten years and *potentially* could be used for as much as thirty years, it's probably best to design it to stand up to new technology for a hundred years or so if possible. Because if it's still secure fifty years after people quit using it, that's all well and good, but if it becomes insecure *while* people are still using it, that's bad. A hundred years is overkill, of course, but overkill is *good* in this context.

That's assuming, of course, that it doesn't create serious usability problems. Trying to implement a password hashing system that will stand up for a hundred years is probably doomed to failure for this reason. With current hardware you'd probably have page swapping going on every time somebody logs in, which would be bad. So fine, you end up backing off from that pie-in-the-sky goal a bit. But within the limits of what _is_ (reasonably) practical, you should do what you _can_, not just what you think you _have_ to do.

So if using an overkill amount of salt implies also a longer and more expensive hash, that's good, because you probably should be using a longer and more expensive hash anyway, if you possibly can. I believe the OpenBSD crowd has this one right.

And as I said, the limitations of a known and respected algorithm are a fairly good reason for limitations on salt and password length, because there is significant security value in using a known and respected algorithm.

> On the other hand, even 64 bits of salt is quite paranoid anyway.

Yeah, but if 128 bits is *more* paranoid, and current hardware is capable of handling it, then it's better. The question isn't (or shouldn't be) "How paranoid is paranoid _enough_?" but rather "Exactly how paranoid can we be without creating significant usability problems?" The former question

Salty

[Anonymous Coward]

Repeat after me: I will salt all my MD5 passwords.

MD5 Lookup Site & Names

[eldavojohn]

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/ 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. Also, as the blog mentions, this discussion is worthless if WordPress used salting which is related to nonces used in security engineering. I think that stuff has been around for, what about five years now? Wake up WordPress!

Re:MD5 Lookup Site & Names

[HTH NE1]

Where was that site in 2002 when people were trying to hack the new TiVo backdoor code?

Re:MD5 Lookup Site & Names

[PFAK]

He can't be much of a "security researcher" if someone hacked his own website.

Re:MD5 Lookup Site & Names

[the_fat_kid]

Just because he "researches" something doesn't make him good at it.
If he claimed to be a "security expert" then he would be a liar.
as it is he is, at worst, a fool.

Re:MD5 Lookup Site & Names

[Anonymous Coward]

The greatest security expert in the world couldn't create a useful (dynamic content) website which is provably unhackable. Only a website which is probably very hard to hack can be created.

If you think otherwise, I challenge you to prove it.

Re:MD5 Lookup Site & Names

[Anne_Nonymous]

That's remarkably close to my password hash:

> Do0d+H!$p@SsW0rD!$t0ta1y$eCuRe

Re:MD5 Lookup Site & Names

[kbielefe]

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.

Re:MD5 Lookup Site & Names

[DaFallus]

And sure enough, if you read the comments to the blog, there is a site called http://md5.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

I have to agree with everyone else so far, pass the Salt.

Re:MD5 Lookup Site & Names

[joNDoty]

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!!!

Re:MD5 Lookup Site & Names

[Cairnarvon]

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

Re:MD5 Lookup Site & Names

[ajs]

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:MD5 Lookup Site & Names

[maxwell demon]

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!!! Well, to type your password anywhere but on your password prompt is just plain silly. In addition to being stored there, it was also transmitted in plaintext over the net, nicely packaged with your IP ...

Re:MD5 Lookup Site & Names

[jmdc]

It seems you need to use a really abysmal password for google to find the hash. Here are a few examples of passwords you should not use that google does not find hashes of (at least as of now(11/20/07)):

• p4assw0rd1
• path2destruction(All your base reference)
• tomatobanana (this is just a silly concatenation of 2 dictionary words)

Re:MD5 Lookup Site & Names

[totally bogus dude]

Yes.

Re:MD5 Lookup Site & Names

[PFAK]

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:MD5 Lookup Site & Names

[slater86]

you see his website was hacked, so he researched it.

this automagically makes him a security researcher. very self explanatory really. his certificate is still in the mail.

Re:MD5 Lookup Site & Names

[Ossifer]

md5oogle.com (http://md5oogle.com) is what you want...

Re:MD5 Lookup Site & Names

[EraserMouseMan]

Google helped? Rednoize.com helped.

Re:MD5 Lookup Site & Names

[msormune]

Not to mention you just posted the information on Slashdot... change the password now dude.

Re:MD5 Lookup Site & Names

[ArsenneLupin]

hanks for warning me. I tested to see if my password was in there... it is now!!! ... and so is 87867d411aaca050da20080fecbfc956

Re:MD5 Lookup Site & Names

[Drysh]

I checked some passwords hashes in that site.. My algorithm for passwords worked every time: instead of using a word, use a word plus the site name, ie, password + "google" or "slashdot" for this test. It recognized the normal hashes, but didn't recognize these:

5e44e93c36f6dd3382a2a424bbe08e4f (godgoogle)
t71f7474bba0fd9038e22b2b7b28068bd (godslashdot)
a9ed4bf50a15669c1a59897b3115a6b7 (mypasswordgoogle)
1d2f9e31e31e1b574b0657d5a7e0bf18 (mypasswordslashdot)
feb11cfdc86158e036f435b2f8a1f9a2 (passwordgoogle)
29e4032e69bde22c5bc645a1e3bc7e5a (moneyslashdot)

It recognizes the hashes for money, god, mypassword, and password. But adding the site name made them much stronger. The bonus is: it's very easy to remember the password created this way.

Re:MD5 Lookup Site & Names

[Anonymous Coward]

Hey, stoopid idea:
you can use MD5 hashes to sign your posts with cryptic messages!

Put this through rednoize:a602dc4d6b16b615be62b9839a6d419b

Obligatory

[Anonymous Coward]

In Soviet Amerika, MD5 passwords crack you.

Re:Obligatory

[CrazyJim1]

What about the flip side: Using Crack to Google MD5 passwords?

Re:Obligatory

[Yubastard]

now that's comedy! :D

Don't panic!

[Anonymous Coward]

The password he searched for was 'Andrew', so it's not too surprising he found it in google. Any non-dictionary password should still be safe.

Re:Don't panic!

[roguetrick]

You never have used rainbow tables have you? You're in for a rude awakening.

I wouldn't be too alarmed.

[morgan_greywolf]

Most MD5 password hashes, such as those used in *nix, are salted, 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.

Re:I wouldn't be too alarmed.

[betterunixthanunix]

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...

Re:I wouldn't be too alarmed.

[SevenDigitUID]

That is totally unfair to the wordpress developers. Just because they don't care doesn't mean they don't understand.

Re:I wouldn't be too alarmed.

[cstdenis]

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:I wouldn't be too alarmed.

[nuzak]

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:I wouldn't be too alarmed.

[neoform]

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.

Re:I wouldn't be too alarmed.

[LWATCDR]

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.

Re:I wouldn't be too alarmed.

[xenocide2]

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...

Re:I wouldn't be too alarmed.

[Anonymous Coward]

Yeah, but I'd expect a "security" blog to know better. WordPress's list of vulnerabilities is way too long and is often held up as an example of insecure PHP code. The whole thing is deeply flawed.

Re:I wouldn't be too alarmed.

[morgan_greywolf]

Who cares if you can read a user's password or not? That's why the gods invented the password reset function.

Re:I wouldn't be too alarmed.

[LWATCDR]

Well This was code I wrote myself about 11 years ago I needed a message base and a downloads area for updates and I needed it password protected and different levels of access. So I wrote in perl and mysql in 1996.
Now as why?
Well if you knew how many people can not even find the lost password link you wouldn't ask. Our site isn't Slashdot. It is for our paying customers to get updates to our software and ask questions. If they can not get on right now it is the end of the world for them.
It is MUCH safer to have the passwords stored as salted MD5 hashes and today I wouldn't do any other way. Eleven years ago I didn't have the experience I have now in security. My security actually worked pretty well for the threat level it faced.
Now there was this other site that had the worst security EVER. No need to hack the site. If someone emailed you a link to a message on the message base you could just follow it and have total access. They locked the door but didn't build any walls.

Re:I wouldn't be too alarmed.

[fm6]

That's not as mind-boggling as the fact that you can even access somebody's MD5 hash. Even UNIX no longer considers salting to be adequate protection.

Dark Helmet

[Nate Fox]

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.

Re:Dark Helmet

[KingSkippus]

For the record, this is much funnier than it's been given credit for so far...

Re:Dark Helmet

[krazytekn0]

Uh, nicely plagiarized

Re:Dark Helmet

[Anonymous Coward]

OK, your Geek Card is hearby revoked and your membership placed on hold indefinately pending a full investigation of your Geek credentials! Your sense of humor will be under review as well.

*mutters - geez .... can't even quote Space Balls ....*

Re:Dark Helmet

[krazytekn0]

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. nicely plagiarized

conclusion?

[Sloppy]

Conclusion? Use no password that any other human being has ever used, or is ever likely to use, for any purpose. I think.

Uh, I thought the conclusion (which the article acknowledges near the beginning as a "preclusion") is to salt before you apply your hash function.

Let me guess

[GroeFaZ]

The password was hunter2?

Re:Let me guess

[omnipresentbob]

What's with all the stars in your post?

Salt

[Aram Fingal]

This goes to show the importance of using the technique of adding salt values to passwords before hashing. Also, your salt value shouldn't be a common word ( or something which would make a common word or phrase in combination with something people are likely to use in a password).

5 years?

[Junta]

Try decades! The good old days of Unix even had salts (even if they were just two bytes)

In itself nothing new

[owlstead]

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:In itself nothing new

[CastrTroy]

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.

Alternative to salt

[Anonymous Coward]

Actually an alternative to storing hashes of passwords altogether is Password-authenticated key agreement.

Stealing from wikipedia since this explains it better than I can:

"[a] method to amplify a shared password into a shared key, where the shared key may subsequently be used to provide a zero-knowledge password proof or other functions."

"ensuring that password verification data stolen from a server cannot be used by an attacker to masquerade as the client, unless the attacker first determines the password"

Actually zero knowledge proofs confuse me quite a bit.

just look for "cf99"

[russ1337]

5f4dcc3b5aa765d61d8327deb882cf99 is the MD5 hash for 'password'.....

search enough systems and you're bound to see some doosh has used it.

Great job..

[Shino]

John cracks the hash in 0s and that's even faster than google does.
Do I also get a slashdot story if I crack a SHA1 hash with google?

Re:Great job..

[maxwell demon]

Do I also get a slashdot story if I crack a SHA1 hash with google?

Probably not. But if you crack Google with a SHA1 hash, I'm sure you get one.

Re:Great job..

[eli pabst]

That's what I was wondering. If you knew that salts weren't being used on the hashes, then a bruteforce tool like John would have found an alphabet-only password trivially. If he would have googled "password cracking", he would have been done a hell of a lot faster than try to code his own tool for doing a dictionary attack.

Found my password

[t0nyp40]

Damn it found mine... 286755fad04869ca523320acce0dc6a4

Re:Found my password

[Anonymous Coward]

Damn it found mine... 286755fad04869ca523320acce0dc6a4

Your password is "password\n"? How do you put in the newline at the password prompt?

Re:Found my password

[maxwell demon]

I wonder which password leads to the md5 hash 09f911029d74e35bd84156c5635688c0 ...

Re:Found my password

[Anonymous Coward]

shouldn't you do echo -n 'password' | md5sum
instead of echo 'password' | md5sum

french bitch

[Anonymous Coward]

I just hate douche bags who can't spell.

Re:french bitch

[maxwell demon]

I just hate douche bags who can't spell. Spelling errors can make your password more secure!

Re:RTFA

[eln]

You're correct. You have totally invalidated the points I brought up in my post. Good show.

Sorry...

[HappySmileMan]

But how is this surprising, I've done that many times, it's basically just a quicker way of searching milw0rm since it's likely that at some point every hash has been seen (and therefore cached) by google

milw0rm

[Anonymous Coward]

hmm .. slashdoting the milcracker.. *cowers*

http://milw0rm.com/cracker/insert.php

Also, it is indexed by google :-)
I guess the lesson is to search google first, and if it's not there, submit to the milcracker.

My uneducated respose would be:

[newr00tic]

What about the flip side: Using Crack to Google MD5 passwords? 2343e9f361fea282776586d7056025db

Re:My uneducated respose would be:

[BigDogCH]

2e10a3a8daa59d8980438b70402f69ae

Re:My uneducated respose would be:

[socsoc]

haha I wish I had mod points, or I would...

Re:My uneducated respose would be:

[BigDogCH]

whoops, posted the wrong hash, and clicked submit when task switching...
I was going to post what is probably the most common hash ever.....
5f4dcc3b5aa765d61d8327deb882cf99 = password

Re:My uneducated respose would be:

[beav007]

827ccb0eea8a706c4c34a16891f84e7b

Re:My uneducated respose would be:

[newr00tic]

thanks, intent goes a long way, too. ;)

Re:My uneducated respose would be:

[rmadmin]

My hash is 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re:My uneducated respose would be:

[feargal]

Funny, only yesterday I was trying to access an account on a simple test system which a colleague had set up, but he had neglected to tell me the password he set up for me to first log on with. I looked at the md5 hash and it was exactly that; I thought to myself "That looks familiar, I wonder if Google knows...".

Re:My uneducated respose would be:

[BigDogCH]

I wonder how many people just went to http://md5.rednoize.com/ and tried it out to see if it had already been logged. They type their own password in, and up pops the md5. Well, now they have it logged!

Actually, hitting refresh on that site, you can see how fast their database is growing. After playing with it for a few minutes, it seems to be growing by 1 or 2 per second.

Wouldn't a Strong Password prevent this as well?

[Bryansix]

If you use letters, numbers and a symbol or two then it's not going to be in any database of MD5 hashes.

Been there. Done that.

[this great guy]

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.

Re:Been there. Done that.

[fo0bar]

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?

Re:Been there. Done that.

[wurp]

He just did.

Re:Been there. Done that.

[this great guy]

Do you then let your clients know that you've sent sensitive company information to a commercial third party using insecure channels?

When they ask, yes of course. And they don't care. We all know early phases of the pentest already leak out even more sensitive data (the actual process to take over machine XYZ) over insecure channels (usually network services facing the Internet: HTTP, SMTP, IMAP, etc) through commercial third parties (ISPs routers).

3332e200d6810f65fe32abc8ab316732

[newr00tic]

For the record, this is much funnier than it's been given credit for so far... 0377f0418a4c9df3950729d4fef8c9e8

on a related note...

[sootman]

... 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.

Re:on a related note...

[DamnStupidElf]

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 could index those as well.

Re:on a related note...

[J0nne]

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.

Re:on a related note...

[Anonymous Coward]

mmmm bit torrent

Re:on a related note...

[pclminion]

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 that's been around since paper punch cards and is the basis of efficient lookup of objects in practically every application you've ever used.

Re:on a related note...

[Faylone]

Thank God, indeed, as he could still probably get a patent on it.

Re:on a related note...

[ant_tmwx]

check out metamirrors - it doesn't compute hashes yet, but it stores them & produces metalinks (XML format listing mirrors) for identical files.

Re:just to extend the record..

[Anonymous Coward]

If you agree so heartily then why the hell did you encrypt your agreement?

Man, I need to change my password NOW.

[fo0bar]

Results 1 - 10 of about 101,000 for d41d8cd98f00b204e9800998ecf8427e. (0.04 seconds)

Re:Man, I need to change my password NOW.

[angryphase]

I'd say so, considering there's even a website devoted to it!

97b5930495ceb44ee0503b7ea8eb7941

[Anonymous Coward]

Well, that's obvious: 97b5930495ceb44ee0503b7ea8eb7941

Google indexed already

[sledge_hmmer]

As I write this message, this story has been posted for only about an hour. However, a google search for the hash already throws up this article as the second link. Damn they index the web fast!

Re:Google indexed already

[giafly]

As I write this message, this story has been posted for only about an hour. However, a google search for the hash already throws up this article as the second link. Damn they index the web fast!

Damn straight. Part of my job is microsites and if you're on a subdomain of a high status site the googlebot practically DDOS's you. Completely distorts the click numbers. Of course most of the Web is lucky to get visited every couple of weeks.

Re:Google indexed already

[u38cg]

No kidding. I once posted a product review on my website, a fairly new gizmo at the time, then wandered off to make a coffee. When I came back, I mused, hmm, has anyone else posted a review yet? I searched for gizmo and I was on the front page after no more than 20 minutes. Impressive.

"Not quite right" to parent and grandparent

[abb3w]

Admittedly, both salting and complex passwords increase the size of the database involved. However, there's no reason one couldn't generate those databases as well. In fact, one of the Google results is for an on-line Password hash database. So, all a group of hackers has to do is put the thing online in some manner of distributed storage, and wait for Google to index all the pages for 'em.

Fortunately, the problem grows exponentially with the number of allowable characters. Unfortunately, so does Google's headaches. I suspect Google will take some "don't be evil" measures on this shortly, if only to keep their Data Storage department from needing to give Earth a second moon....

Re:"Not quite right" to parent and grandparent

[rthille]

"That's no moon, that's Google's new data center!"

On the other hand, solar power would be cheap, efficient. cooling would be easy, just hide behind the solar array.
Ping times to earth would suck though...

Re:"Not quite right" to parent and grandparent

[nuzak]

> cooling would be easy

Actually cooling is ridiculously hard in a vacuum. There's a reason you need a fan with your heatsink, and fans don't work. The outside may be cold but there's nothing to carry it away.

Google Hash

[timbrown]

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 and http://www.dragoslungu.com/2007/06/22/google-md5-hash-search-engine/. My interest is that I'm attempting to get Google to index such hashes at http://www.nth-dimension.org.uk/utils/ghash.php. In my case I'm actually attempting to get Google to cache my hashes to minimise my storage costs as rainbow tables take a fair bit of disk space to store although the idea hasn't been particularly successful due to Google algorithms :(.

Credibility?

[MarkLewis]

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:Credibility?

[garompeta]

With all my respect, 596a96cc7bf9108cd896f33c44aedc8a

Re:Credibility?

[Thanatos69]

I know it's somewhat taboo around here to read the article but he does know about rainbow tables:

I could also improve efficiency with a rainbow table, but this needs a large database which I didn't have.

As for the rest of your post... heh, touche... :)

Re:Credibility?

[dgym]

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?

Re:Credibility?

[Anonymous Coward]

Security research people are cracker targets. Remember exactly how Keven Mitnick, may he have a cellmate who likes curly headed boytoys, got caught when he broke into the systems of a security expert and taunted the guy.

Re:Credibility?

[Cairnarvon]

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.

Re:Credibility?

[Antique Geekmeister]

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.

Re:Credibility?

[MimsyBoro]

I also tried some basic passwords.

Although classics like: `swordfish` definitly came up (mainly in md5sum result sites) many other English words have no reference whatsover and also any number letter combination, no matter how short doesn't show up (4 alpha-numeric chars).

So not really worth much.

Re:Credibility?

[pvera]

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.

Re:Credibility?

[neonsignal]

I looked these up on google, and they directed me to some slashdot page...

Re:Credibility?

[etinin]

Perhaps it's due to Slashdot, but all of the hashes you generated are present on http://md5.rednoize.com/, so the previous claim that hashes of common words don't exist in the internet might not be quite true.

Re:Credibility?

[Anonymous Coward]

How the hell is "swordfish" classic?

How about: love, secret, password, god, sex

Re:Credibility?

[settrans]

You were looking up the hashes for those strings plus a newline. Remove the trailing newline and you'll get more results (the last three all return results without a newline).

Re:Credibility?

[Vexorian]

I tried to google those hashes, and voila! I found the source words! (Although it mostly involves the fact that your post just got indexed by google...)

Re:Credibility?

[Thanshin]

Indeed, pickles was a perfectly good password until you all started talking about it.

Re:Credibility?

[Drysh]

9cdfb439c7876e703e307864c9167a15

Re:Credibility?

[edraven]

Baravelli: ...you can't come in unless you give the password.
Professor Wagstaff: Well, what is the password?
Baravelli: Aw, no. You gotta tell me. Hey, I tell what I do. I give you three guesses. It's the name of a fish.
[After several unsuccessful guesses]
Baravelli: Hey, what's-a matter, you no understand English? You can't come in here unless you say, "Swordfish." Now I'll give you one more guess.
Professor Wagstaff: ...swordfish, swordfish... I think I got it. Is it "swordfish"?
Baravelli: Hah. That's-a it. You guess it.
Professor Wagstaff: Pretty good, eh?

Re:Wouldn't a Strong Password prevent this as well

[Sancho]

That's what you think.

09f911029d74e35bd84156c5635688c0

[alx5000]

Mine beats yours 3:1

Re:09f911029d74e35bd84156c5635688c0

[nephridium]

X <-joke

'O
/|\ <--you
/ \

Hint: it's not quantity - it's quality that matters ;)

Re:09f911029d74e35bd84156c5635688c0

[Anonymous Coward]

Hey, hey, don't bash me, I got the joke, it took me awhile to come up with something more common than that :P

How about "don't use your first name As your PW"?

[nobodyman]

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.

Phsaw

[encoderer]

Pshaw!

This is why I all MY passwords are salted hashes that I then re-hash and re-salt. To Taste. ..Check and Mate.

Re:Dark Helmet from President Skroob

[soni.mathe]

827ccb0eea8a706c4c34a16891f84e7b. That's amazing! I've got the same combination on my luggage! Prepare Spaceball 1 for immediate departure! And change the combination on my luggage!

No worse than Subversion

[Antique Geekmeister]

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.

Re:No worse than Subversion

[chochos]

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?

Re:No worse than Subversion

[Antique Geekmeister]

If the Mac subversion client does so, then the client is not the actual Subversion source code, it's been heavily modified. I've not tested it: is it a command line client? If so, what does "svn --version" say?

Re:No worse than Subversion

[chochos]

I built my svn client from source; the configure script even has an option to disable the use of the Mac Keychain (only useful if you're building on Mac). So I guess they added this functionality to the main branch, which could mean it's been around for a while.

% svn --version
svn, version 1.4.5 (r25188)
compiled Nov 15 2007, 14:44:28

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

Re:No worse than Subversion

[Antique Geekmeister]

Well, good. That certainly wasn't present in the 1.3 releases. I don't have a Mac to work with at the moment: can you double check and verify that it doesn't keep a copy of the password in .subversion/ ?

Re:No worse than Subversion

[chochos]

Well I had svn 1.2 at some point but I upgraded to 1.4, so I do have some files in the .subversion/auth/svn.simple dir with "password" and a value in there, but the newer files in there already say "passtype" and "keychain". When I had the older svn I didn't see anything in the keychain so I guess it was using a plaintext file. I noticed the use of the keychain when I installed 1.4 but I never used 1.3 so I wouldn't know exactly when this was included.

Re:No worse than Subversion

[Antique Geekmeister]

I checked out some code: it was in 1.4.0, but not in 1.3.0, so I assume it started with 1.4.x. We should all be using that now anyway, except people stuck with a "7-year" support model such as RHEL releases who cannot be convinced to do such upgrades from non-RHEL repositories.

My Hash

[SJ2000]

09F911029D74E35BD84156C5635688C0

Re:My Hash

[OrangeTide]

hex? you're joking right?

$1$PPTAgWE3$lZtEc7k971.seo6XpSW7N1

Re:My Hash

[tepples]

hex? you're joking right? Yes.

Re:My Hash

[OrangeTide]

perhaps you weren't aware of my site http://09f911029d74e35bd84156c56356.rm-f.net/

Security through obscurity

[megaditto]

But nobody will guess that the search string "jennifer lopez" is my actual password. I am still safe for now.

Re:Security through obscurity

[pixr99]

Posting to negate the accidental "-1 Overrated" I just handed your post. +1 Funny is what I wanted but I've had so much coffee this morning that I'm twitchy.

new worm spreading

[ThinkOfaNumber]

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 to see if your password is 'safe'.

72a43b3d7fb98a838235d40688d2c0fd

[newr00tic]

Well, that's obvious: 97b5930495ceb44ee0503b7ea8eb7941 f708970c4fa7742358b61d7345647930

Comment removed

[account_deleted]

Comment removed based on user account deletion

No, it means that as the attacker...

[jnf]

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 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.

Re:RTFA

[that this is not und]

Well, we're all just having fun. You're the one gathering up "+5 informative" karma...

Re:Salt.. .so then develop

[davidsyes]

a rad ass custom mod chip that the user injects into the cerebral cortex and obdulla loongggatta and up down undah. The user then develops Tourettes Syndrome out the ass and has shit for brains now and only has to utter some crazy fucking ass phrase to seed a crazy fucking password in the solid-state gene-erator cuz they've gone fucking goddam crazy over that motherfuckin' chip in their ass and brain.

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...

Hash DBs have been around for years.

[smitth1276]

Like GData. That has been around since the summer of 2005.

Finding your hashes on google

[Tribbin]

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.

Hold the pepper...

[Schnoogs]

but can I get some salt with my password? ;)

bash.org

[Anonymous Coward]

I laughed long and hard at the 'hunter2' tag. Little things like that are what keeps me coming to /.

HMAC

[pestilence669]

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.

Hashlist++

[TarZ]

md5oogle.com
Search: the hashes [8df045510696cde422acede21a727c1b]

There were no results found for, "8df045510696cde422acede21a727c1b"

Search: generate an md5 hash [goooogle]

Result: 8df045510696cde422acede21a727c1b

Search: the hashes [8df045510696cde422acede21a727c1b]

Result: goooogle

Oops.

Re:Hashlist++

[Ossifer]

Oh my god -- it's LEARNING!!!

Salt it

[kauttapiste]

Use no password that any other human being has ever used, or is ever likely to use, for any purpose.

I'd take that advice with a pinch of salt. :-)

Nonsense

[Anonymous Coward]

Bruce Schneier ran the code-base through crypt first and then audited the hash with a single roundhouse kick. He then fixed all the flaws by pile-driving his server.

I pepper my hash...

[EmagGeek]

Salt is nice, but pepper is better.

had to check...

[Paul Rose]

Parent is funny even if you don't know what d41d8cd98f00b204e9800998ecf8427e is the hash of, but I had to check...

To save you time it is the MD5 hash of an empty file:

md5sum /dev/null

d41d8cd98f00b204e9800998ecf8427e /dev/null

Re:had to check...

[fo0bar]

FYI, you can also do:

echo -n | md5sum

The "-n" is needed by by default, echo wants to put a linefeed after everything.

I want to thank you all...

[bjk002]

... As I read through the replies to this article it occurred to me I should investigate the possibility of purchasing large quantities of metal futures. So I headed over to http://www.metalprices.com/ and realized it was a good time to buy aluminum and tin.

Thanks again!!

Make the hashing inefficient

[pilybaby]

OK, so we all agree that we should salt passwords with something. But even without that we should also make the hashing algorithm as slow as possible, perhaps running MD5 recursively 10 times, or using a slower algorithm on itself multiple times, or running different algorithms on the output of others etc. Most of the time this isn't going to have a significant effect on performance of the whole system and it also becomes infeasible to create a rainbow table because each hash will take a lot longer to create.

on salted hashes...

[Anonymous Coward]

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.

Reverse MD5 in multiple databases

[Killerwhile]

The site http://md5.noisette.ch/ try to reverse MD5 hashes in looking up into multiples other existing databases. It "knows" most of the hashes posted into the comments...