Ars was briefly hacked yesterday; here’s what we know

Readers, please change your passwords.

Read the whole story

 

[epixoip]

Hi everyone. This is noted password cracking expert and D-list Internet celebrity Jeremi Gosney. You might remember me from here, here, here, here, here, here, or even here or here.

I would like to take a minute to address some of the comments being made about the password hashing algorithm that is used by the forum software Ars is using. Let's have a look at some of those comments.

pk![/url]":197g7ac3]MD5, really? After having printed several articles on password cracking I'd have hoped you'd at least have leveraged a stronger hashing algorithm.

Abhi Beckert[/url]":197g7ac3]
2,048 iterations is not enough to prevent a brute force attack on MD5.

d0x[/url]":197g7ac3]
Seriously? Ars themselves have posted many articles about this very method of encrypted password storage to be easily breakable either via brute force or with rainbow tables.

Threz_[/url]":197g7ac3]One the one hand, Ars calls the use of MD5 hashes for storing passwords as "unfortunate and irresponsible", and on the other (above) uses it as a way to argue that the passwords were well-"encrypted." Which is it?

FF22[/url]":197g7ac3]
No wonder your server was hacked if you really thought running MD5 multiple thousand times over the password would harden the hashes by any means. If anything, it weakened them.

Wow. Powerful stuff there. Too bad these armchair experts are all dead wrong.

First, when we talk about MD5 being a poor and irresponsible choice for password hashing, we're talking about raw MD5. As in a single, unsalted iteration of MD5. As in md5($pass). And as the keen Ars reader will note, the reason this is a bad choice has nothing to do with any cryptographic weakness in the MD5 algorithm itself. It's simply because MD5 is very fast and very amenable to acceleration.

One of the ways we make an algorithm resistant to acceleration is to salt it and iterate it. And no, iterating a hash does not weaken it, that's utter horseshit. Iterating a hash is what almost all password hashing algorithms do, including all crypt(3) algorithms, PBKDF2, and even bcrypt.

Ars uses phpBB, which uses the Openwall PHPass password hashing algorithm, designed by none other than the venerable Solar Designer himself. PHPass uses salted and iterated MD5 to hash passwords. It is similar to md5crypt with some key differences, and even similar to PBKDF2 to some extent. And while it may not be the best choice for password hashing, it is a solid one.

To see just how solid PHPass is, let's look back at another famous breach which used PHPass: Forbes. Back in February, Forbes had 1,071,961 password hashes dumped by SEA. Out of those 1,071,961 password hashes, 1,071,734 were hashed using PHPass.

Now as the keen Ars reader will recall, normally us professional password crackers can get a public dump 85-95% cracked within a rather short period of time. And indeed, the 227 passwords that weren't hashed with PHPass were 100% cracked in just a few short minutes. But after 10 months, we currently only have the Forbes PHPass hashes 16.19% cracked. Yes, you read that correctly. We've only managed to crack 173,548 -- or 16.19% -- of the Forbes passwords, and most of those were Top 20K passwords.

If you want to put this into "OL Hashcat" terms, a single R9 290X can pull ~ 12.2 GH/s on raw MD5, but only 3 MH/s against PHPass. Divide that by 1,071,734 unique salts, and that means our effective speed is only 2.86 H/s. That's beyond properly slow. Multiply that by 100 GPUs and that's still only 286 H/s. We can't do very much with that, and that's why this list is only 16.19% cracked.

So obviously PHPass is pretty good at what it does, and Ars has done absolutely nothing wrong by using this algorithm. It is perfectly suitable for what this site is. I've said before that password hashing is like an insurance policy, and Ars has bought you ample time to change your passwords.

And that's the way it is.

 

[epixoip]

Addressing a few more comments here,

Powerlord[/url]":2gatdqci]
To put this into perspective, Linux distros were using 1000 iterations of salted MD5 15 or so years ago. And had switched away from it 10+ years ago.

The use of MD5 is not why md5crypt was deprecated. It was deprecated because it used a fixed iteration count of 1000 rounds, and did not employ a variable number of rounds as say PHPass does. The move from MD5 to SHA2 was done for NIST "compliance," for a lack of a better word. Same reason why MD5 was changed to SHA512 in Drupal's implementation of PHPass. SHA512 was chosen over SHA256 as the default for its performance on 64-bit systems. Also, this change was only made in late 2008, which was only 6 years ago, and it still took a couple years to find its way into the distributions (SLES being the only exception, which used Openwall's bcrypt patch.) And FreeBSD didn't make the switch until 9.1 (December 2012.)

Threz_[/url]":2gatdqci]Considering the article I quoted was talking about a single user putting a rig together to reach 350 billion hash/sec rates... an additional couple thousand hashes isn't really all that much longer. These passwords leaked from Ars will be cracked pretty quickly.

As the owner of said rig (which is now 6x faster than that, by the way), I'd like to say that no, the Ars passwords likely won't be cracked quickly. PHPass is not NTLM. As I said, on the Forbes dump (PHPass with 1M+ salts) we can only pull about 280 H/s on our cluster.

pqr[/url]":2gatdqci]Sure. Why assume salt is unknown? Typically it is in same DB as hash itself. (In other words effective speed is order Mhash/sec in targeted attack.

I'm not assuming an unknown salt -- those numbers are with a known salt. With salted algorithms you incur a factor of N slowdown for each unique salt, as each plaintext candidate has to be re-hashed with each unique salt. So 3 MH/s with 1M unique salts == 3 H/s effective rate.

Edit: s/occur/incur/

 

[epixoip]

Bengie25[/url]":32eidf13]
Technically, the he did mention that "salting" makes cracking take longer. pqr may have assumed the poster meant it took longer because now you have to guess the salt, because it's ridiculous to think the salt adds a reasonable amount of extra work.

pqr needed to read through the minor mistake, because it was meant that salting stops rainbow tables and iterations make hashing talk longer. The rest of the post was spot on, just the minor "salt" mistake.

There was no mistake made, and you obviously don't understand how salting works. It does indeed add a reasonable amount of extra work. You incur a factor of N slowdown for each unique salt. 1M unique salts == 1M times slower.

 

[epixoip]

Gern Blaanston[/url]":7c4tdeqi]So far, all the discussion has revolved around the good/bad points of MD5. And while it's all quite interesting, I find the first sentence of the article more troubling:

"an Internet intruder gained access to one of the Ars Web servers"

These intrusions seem to be becoming more common and there really seems to be a systemic problem of people not taking security seriously (despite paying lots of lip service). Don't get me wrong, strong encryption on your database of user passwords is a very good thing. But not letting people get to that database in the first place is, in my opinion, even more important.

Not much you can do about 0days. Webapp has to talk to the database, if you compromise the webapp then you also have access to the database. This is why we employ strong hashing -- it's an insurance policy in the event of a breach.

 

[epixoip]

pqr[/url]":3neybash]
Figured out how this detour could have been avoided. Units of that rate should be 3 hashes/sec/account Whereas I thought you were solving different problem (unknown salt-assignment) which means 3 hashes/sec/salt for given account.

No, I'm afraid you're still not getting it. I was most certainly not solving the problem of unknown salt assignment. Again, my calculations were with a known salt for each hash.

The overall effective speed of the entire attack would be 3 H/s. As in, if you were to load this list up in oclHashcat and start cracking it, oclHashcat would report the speed as 3 H/s. As in, you can only try three candidate passwords per second against all hashes. Except it would be even slower than that on a 290X because AMD has a shitty memory controller and you incur a penalty for loading a hash list of that size. Here, let me show you. Actual attack with a 290X against the Forbes PHPass hashes.

Session.Name...: oclHashcat
Status.........: Aborted
Input.Mode.....: File (/home/epixoip/rockyou-sorted.txt)
Hash.Target....: File (/home/epixoip/forbes-php.hash)
Hash.Type......: phpass, MD5(Wordpress), MD5(phpBB3), MD5(Joomla)
Time.Started...: Tue Dec 16 16:50:26 2014 (15 secs)
Time.Estimated.: Wed Aug 5 00:59:31 2015 (231 days, 7 hours)
Speed.GPU.#1...: 1 H/s
Recovered......: 3/1071734 (0.00%) Digests, 3/1071734 (0.00%) Salts
Progress.......: 11714560/15347819261966 (0.00%)
Skipped........: 180224/11714560 (1.54%)
Rejected.......: 0/11714560 (0.00%)
HWMon.GPU.#1...: 0% Util, 54c Temp, 100% Fan

So in reality, only 1 H/s effective rate. Thanks AMD.

Again, the reason for this is because each plaintext candidate has to be re-hashed with each unique salt. This is where your factor of N slowdown comes from. So if you have 1M salts, you have to hash one candidate 1M times in order to compare it to the hash list.

Edited to add oclHashcat output

 

[epixoip]

pqr[/url]":mkwl97hn]So be not afraid, I am very much getting it (perhaps you are not getting this last statement, or not wanting to, but that I leave to you to deal with).

You said the units should have been expressed as "3 hashes/sec/account", and that is wrong. That is what leads me to believe you are still not getting it. The units per account would be 3 MH/s/account.

 

[epixoip]

Jedakiah[/url]":2wg2oz9m]

epixoip[/url]":2wg2oz9m]
There was no mistake made, and you obviously don't understand how salting works. It does indeed add a reasonable amount of extra work. You incur a factor of N slowdown for each unique salt. 1M unique salts == 1M times slower.

Evidently I don't understand how it works either, which is quite embarrassing. I was under the impression that a salt is a random string added to the end of the password before it is run through a hashing algorithm. So you generate a random string like "Ar2cjWo3rc", append it to the end of your password "hunter2Ar2cjWo3rc", then you store the hash and the salt in your database. Of course typically your hashing algorithm stores the salt and hash together in the same output string saving you a column in the database. Where does the 1 million figure come in? The only way I can picture a hacker having to run a million attempts on each hash * your iterations is if you are using a precomputed list of a million hashes stored elsewhere, and randomly select one each time a user registers. The you store no info about which one you selected. If so then Ars too has run a million attempts on each hash every time a user tries to log in. That whole system seems odd, mostly because I have never seen it implemented before. Why store precomputed hashes instead of just bumping the iterations? It would add complexity and tax the database. I am assuming I am way off here, hence my question about how this works.

Don't feel embarrassed. Salting (and even password hashing) is a subject that many believe they understand, but few really do. We just had a very heated debate about salting on the Password Hashing Competition discussions mailing list, in which it was evident that several of the people involved with the competition didn't really understand salting either.

I really liked the way Thomas Pornin recently described salting, so I'm going to paraphrase his explanation.

The point of salting is to avoid sharing the cost of attacking a set of password hashes.

An attacker who has a list of unsalted password hashes can compute the hash function once for each password candidate, and compare it to the list of all hash values. So with an unsalted password hash, an attacker can attack N passwords at the same cost as attacking one password.

Salting, however, turns a single password hashing function into a family of many functions. The salt is simply then the index of which function to use, within the family of functions. Having a family of functions, with as little reuse as possible (unique salts), defeats cost sharing under the assumption that the hashing work performed with one function of the family yields no information on the hash values computed with another function.

To illustrate this explanation, let's use an extremely simple example: md5($salt.$pass). You should never use this algorithm to hash passwords, but it is a very simple algorithm and thus suitable for explaining how a salt works.

And let's say we have a user database which looks something like the following:

user1:salt1:ee40a2e96211d42215d34c00847b6fc0
user2:salt2:c2cb9c500aa1aa632a9cb27b7e594636
user3:salt3:89766e7bf56f50206f592c9edb672e21
user4:salt4:588f94d3f14f5c1075192350a8768dd4

Our hashing function is md5($salt.$pass), and we have four unique salts: "salt1", "salt2", "salt3", "salt4". So our family of functions becomes:

md5("salt1".$pass)
md5("salt2".$pass)
md5("salt3".$pass)
md5("salt4".$pass)

Now let's say we wanted to try to crack these hashes. Let's use a simple wordlist comprised of only three words: "12345", "password", and "secret". If this were an unsalted function, we would only have to hash each word in our wordlist once, and compare the resulting three hashes to the hashes in our password database. But this is a salted algorithm, so each password candidate has to be hashed with each function in our family of functions.

In other words, instead of doing:

md5("12345)
md5("password")
md5("secret")

We instead have to do:

md5("salt1"."12345")
md5("salt2"."12345")
md5("salt3"."12345")
md5("salt4"."12345")
md5("salt1"."password")
md5("salt2"."password")
md5("salt3"."password")
md5("salt4"."password")
md5("salt1"."secret")
md5("salt2"."secret")
md5("salt3"."secret")
md5("salt4"."secret")

Since we have four unique salts, we incur a 4x slowdown versus raw MD5 as we are doing 4x as much work. If you have 1M unique salts, you would incur a 1000000x slowdown.

The defender does not incur this slowdown because they are only testing one user-supplied password candidate against just one salt. When user4 authenticates with the password "arstechnica", the site simply has to look at the user database and find user4's salt, then test if md5("salt4"."arstechnica") == 588f94d3f14f5c1075192350a8768dd4. If it does, then the user is authenticated.

Again this is a very simple example, using an algorithm that you should never use. But it should be easy enough to understand the principle.

 

[epixoip]

dillweed81[/url]":5jymbft4]Can someone please explain to me how 2048 iterations of MD5 plus a salt supposedly reduces hashes per second to the 3 digits? To me this seems like 2048 MD5 operations and 2048 string concatenations. This means the cracking rate should be the number of MD5 ops per second divided by 2048, roughly. Why is it not? What is making it slower than that? Each salt has to be unique, that's the definition of a salt, but the salt, as I understand, is stored inside each user row. So the salt effectively shouldn't significantly affect the runtime, it merely prevents precomputed cracking. Am I misunderstanding his metric? Is he trying to calculate the hashes per second on average to crack *every* hash rather than a single hash? If so, that seems very misleading; hashes per second is assumed to be the rate to crack a single hash.

Salts do more than preventing pre-computed attacks. From a functional perspective, there is no difference between pre-computing hashes and attacking hashes in parallel. Salting defeats both equally.

So it's not simply MD5 ops / 2048, it's MD5 ops / 2048 / # of unique salts.

 

[epixoip]

drukov[/url]":16w7fjri]

epixoip[/url]":16w7fjri]

If you want to put this into "OL Hashcat" terms, a single R9 290X can pull ~ 12.2 GH/s on raw MD5, but only 3 MH/s against PHPass. Divide that by 1,071,734 unique salts, and that means our effective speed is only 2.86 H/s. That's beyond properly slow. Multiply that by 100 GPUs and that's still only 286 H/s. We can't do very much with that, and that's why this list is only 16.19% cracked.

That's completely wrong. Salts do not slow down bruteforce cracking beyond obscuring users who use the same password. The effective speed is still 3 MH/s.

Sorry, but you're completely wrong. I've explained why this is the case several times. I'm sorry if you are not able to understand why this is true.

 

[epixoip]

dillweed81[/url]":2z7sqc8g]epixoip is a professional password cracker, not a professional penetration tester. He cares about cracking massive data sets, which does not always align with black hat goals. I work in infosec and have participated in some red team exercises.

Slow down, cowboy. Not only am I a professional penetration tester (I consult on the side for a large security consulting services company), but I too have an extensive background in Infosec, having run the security & compliance department at a publicly-traded company for a number of years.

But you are correct, salts do nothing to slow down an attacker targeting a single account. And yes, bcrypt would have been better than PHPass. As I said, it's not the best choice, but I still stand by my statement that it is an appropriate choice. As you work in Infosec, I'm sure you're familiar with the concept of Threat Modeling.

dillweed81[/url]":2z7sqc8g]
With 2,048 iterations, it is roughly 4,000x slower than a single round of MD5. This is much better than MD5 but is still much faster than what industry standards recommend. The rounds would have to be set to 130-200k to get closer to industry standards. Obviously it could be configured to use that many rounds, but Ars did not configure it that way (possibly due to performance concerns).

Actually it can't, PHPass only supports up to 2^16 rounds. It should further be noted that OWASP is not the authority on password hashing, and certainly not the standard. Currently, there is no standard, and that's a large part of why the Password Hashing Competition exists.

 

[epixoip]

dillweed81[/url]":q5qeho6n]OWASP's recommendations for PBKDF2 are 128,000 iterations in 2014

I am unable to find where OWASP recommends 128,000 iterations in neither their article on password hashing, nor their article specifically pertaining to PBKDF2.

So where did this number come from?

 

[epixoip]

Sc00bz[/url]":wqiq2bta]

epixoip[/url]":wqiq2bta]

dillweed81[/url]":wqiq2bta]OWASP's recommendations for PBKDF2 are 128,000 iterations in 2014

I am unable to find where OWASP recommends 128,000 iterations in neither their article on password hashing, nor their article specifically pertaining to PBKDF2.

So where did this number come from?

I wouldn't take OWASP as an authority on password hashes when they suggest PBKDF2-HMAC-SHA1 with an output of 192 bits...

That said PBKDF2's minimum suggested iteration count in 2000 was 1,000 and should probably double ever 2 years so 2^((2014-2000)/2)*1,000=128,000. This is where that number comes from I know I've said similar a few years ago.

Hi Steve!

Yeah, OWASP can be a decent resource for some things, but they're hardly an authority by any stretch of the imagination.

Anyway, 128k iterations is probably fine for key derivation, but I'm not sure I'd ever recommend anything near that for password hashing. But then again also I'd never recommend just blindly following someone's advice on iteration count. Should always be chosen based on benchmarks and metrics.

 

[epixoip]

Sc00bz[/url]":dbvzcf73]

epixoip[/url]":dbvzcf73]
Anyway, 128k iterations is probably fine for key derivation, but I'm not sure I'd ever recommend anything near that for password hashing. But then again also I'd never recommend just blindly following someone's advice on iteration count. Should always be chosen based on benchmarks and metrics.

Yes, I would not really recommend PBKDF2 with 128k iterations because it's slow as shit. Since it can't take advantage of SSE2, AVX2, or AVX512 (soon). The problem with PBKDF2 is that Moore's law went parallel and PBKDF2 is sequential. Thus over time, hurting the defender.

Also PBKDF2 with 1,000 iterations back in 2000 was for optimized compiled code not PHP. So really as a defender you need to lower your iteration count because your code runs slower. This sucks but otherwise it will take too long.

Excellent points indeed!

 

[epixoip]

locolocol[/url]":2iuy43yd]

epixoip[/url]":2iuy43yd]Hi everyone. This is noted password cracking expert and D-list Internet celebrity Jeremi Gosney. You might remember me from here, here, here, here, here, here, or even here or here.

Ha, when I read this, I immediately thought of:
Hi! I'm Troy McClure, you may remember me from such films as...

Yes, that was the joke

 

[epixoip]

seajack0[/url]":19z4bzb1]Why isn't this pinned to the front page? You guys always vilify other companies for allowing themselves to be hacked and smear it all over the front page, only to bury your own site getting hacked in the sidebar. What gives? Also, MD5? What is this, 2004?

It was pinned at the top of the page all day yesterday and this morning, but seems to have been replaced this afternoon by arguably a more important story.

Regarding MD5, you obviously didn't bother to read any of the comments, let alone the featured comments, before posting your own comment.

 

[epixoip]

mehaase[/url]":353uo48y]

DeadMG[/url]":353uo48y]Even with an algorithm as weak as MD5, 2048 iterations plus salt isn't too bad.

Some obscure news organization covered a GPU cluster two years ago that could compute 180 billion MD5 hashes per second. The Ars minimum password length is 6 characters (yikes) and I can't remember if it has any password complexity requirements. I'll assume mixed case and alphanumeric just to be charitable. That cluster cracks such a password in about 5 minutes.

An "Ars hash" takes ~2000x longer to compute than a single round of MD5. That GPU cluster can still compute ~90 million "Ars hashes" per second. This stretches 5 minutes into about 7 days.

You are referencing single hash speeds, and failing to account for the impact of salting.

As the owner of the rig you are referencing, I'd highly recommend reading the promoted comments, in which I already addressed this concern.

 

[epixoip]

mehaase[/url]":1hd0l5tc]
Yes, I am looking at single hashes, and I explicitly said that in the first paragraph of my post

Sorry, I must have missed that.

mehaase[/url]":1hd0l5tc]
If there were any factual or mathematical errors in my post that you wish to dispute, please do.

Ok. Your figures are inflated by 50 ~ 200%. PHPass with 2048 rounds isn't ~ 2000x slower than raw MD5 as you reckoned, it's more like 4066x slower than raw MD5.

oclHashcat + R9 290X can pull about 3 MH/s on PHPass single hash brute force, and about 1.5 MH/s on single hash wordlist-based attacks. So with 25x 290X you're looking at 37.5 ~ 75 MH/s depending on the attack, minus ~20% overhead for distributing the workload, so more like 30 ~ 60 MH/s in reality.

To quantify that, that's about five hours just to run through rockyou.txt with d3ad0ne.rule, and 13.6 days to brute force lengths 6-7. And that's with a 25-GPU cluster.

So yeah, it's not mind-numbingly slow, but it's still slow enough that we will be limited in the types and variety of attacks we can run. Any password with even a hint of complexity is fairly safe at those speeds. More than enough time to change your passwords.

 

[epixoip]

mehaase[/url]":3h0kkidg]This is an interesting claim. I had never looked at PHPass source code before today, so I just took a gander. It's about what I expected: a tight loop around the core MD5 algorithm. I don't doubt your claim that this is ~4000x slower than a single MD5 (which means my estimate was off by a factor of 2), but this implies that the PHP implementation has an overhead cost of 100% (compared to an unrolled loop in native code). I'm guessing that memory allocation and string concatenation are probably the most expensive operations. If the same algorithm was implemented in a more efficient language, then the overhead could be reduced drastically. Out of curiosity, do you know if oclhashcat calls into PHP to crack PHPass or does it have its own native implementation?

Well no, oclHashcat certainly doesn't call PHP to crack PHPass, that would not be possible for GPU cracking. oclHashcat kernels are written in OpenCL (AMD) and CUDA (Nvidia), and it has its own heavily-optimized kernel for PHPass.

PHPass might be 2048x slower than raw MD5 in PHP, I don't know. Probably a bit slower than that due to the string concatenation. But the reason PHPass is 4066x slower than raw MD5 in oclHashcat, and not 2048x slower as one might logically conclude, is that there are several optimizations for raw MD5 (and indeed most all raw hashes) that we cannot apply to PHPass. In "oclHashcat speak", these optimizations are:

* Precompute-Init
* Precompute-Merkle-Demgard
* Meet-In-The-Middle
* Early-Skip
* Not-Salted
* Not-Iterated
* Scalar-Mode
* Raw-Hash

In other words, with salted and iterated MD5, we can't take any shortcuts such as pre-computing, partially reversing, and exploiting early-skip checks like we can with raw MD5. And the reason wordlist-based attacks are slower is because we can't take advantage of the zero-byte optimization for short inputs.

mehaase[/url]":3h0kkidg]And this is where I defer to your expertise. I assume that the 290X must be one of the best cards out there for cracking? So how much do you think this technology has improved in the 2 years since you built your cluster, in terms of MH/s/$? And where do you think it will be 2 years from now? Or 10?

Yes, the 290X is currently the best in terms of Perf/$. GPU speed doubles roughly every 4 years (each generation is usually ~25% faster than the last.) We upgrade our clusters about every 12 months.

mehaase[/url]":3h0kkidg]
That was really my original point. Hardware will get continue to get faster and cheaper and more attacks against MD5 will be announced. PHPass+MD5 isn't tenable in the long run. Replace PHPass+MD5 with bcrypt (and select a suitable work factor), and then the 25 GPU cluster plummets from 30 MH/s to 30 hashes/s.

Well no, it wouldn't plummet to 30 H/s. More like 1 KH/s * 25 = 25 KH/s for 08.

But I don't understand why you're so hung up on the use of MD5 in PHPass. In the absence of better pre-image attacks, there's nothing wrong with basing a password hashing function on MD5, as the cryptographic weaknesses of MD5 do not apply to the context of password cracking. Just as bcrypt can run at several KH/s with a low work factor, PHPass supports up to 2^16 iterations. So you can select a suitable work factor for PHPass, too.

Look, no one is arguing that PHPass is better than bcrypt, that would be absurd. But in no way should anyone draw the conclusion that PHPass is a poor password hashing algorithm, especially if your basis for that decision is "because MD5."

 

[epixoip]

Sc00bz[/url]":1fnjgfvw]I'll cut you off there because you go into crazy town.

You're too funny, Steve

 

[epixoip]

Rainbird[/url]":1h6ab70j]

sraboy[/url]":1h6ab70j]Maybe it's just me, but I'd appreciate it if a notice about the breach were posted at the top of the front page, or if I got an email.

You did get an e-mail.

And it was at the top of the page for a day and a half.

 

[epixoip]

mehaase[/url]":1ox8homz]I'm not "hung up" on any particular algorithm. Let's just say that there are several simple ways that Ars could have turned 14 days into 14 years (or more). If this was any other site, I'd shrug and say, "oh well." But Ars covers password cracking! I can't believe that you and your buddy fail to see the irony here.

Password hashing can't do very much to help those who choose a stupid password, especially if you are only going after a single hash. Even with bcrypt at a cost of 2^8, you can still test ~110 million passwords a day on a single CPU, which is enough to run through rockyou.txt + best64.rule in about a week.

 

[epixoip]

Once again: the cryptographic weaknesses of MD5 have nothing to do with why it is a poor choice for password hashing. The fact that MD5 is cryptographically broken is irrelevant when talking about password hashing. Unless the algorithm is horribly, horribly broken (e.g., Office97 (MD5 truncated to 40 bits), XSHA1 (not to be confused with SHA1), and MySQL 323) you're not going to find an arbitrary collision for a short input. What makes MD5 a poor choice for password hashing is the fact that it is a very fast algorithm that is quite amenable to acceleration. Iterating and salting MD5 mitigates that. There is nothing wrong with basing a KDF or password hashing function on MD5, and there are very specific and valid reasons why Solar Designer chose to use MD5 in PHPass.