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

Readers, please change your passwords.

Read the whole story

 

[fabioromeo]

This account was left inactive, but now I want to delete it and there's no option for that. Can you please post some directions for account removal?

 

[pqr]

Jedakiah[/url]":ymmeg4y0]

epixoip[/url]":ymmeg4y0]

Bengie25[/url]":ymmeg4y0]
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.

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.

No what he means is that with no salting, you make one password guess, hash it (slow), compare result to ALL hashes you stole (loop but fast). In other words you're cracking all passwords simultaneously so need to sweep through parameter space only once and capture all of them. If there is salt, you need to sweep for every single account. Of course in any case you sweep intelligently and try more likely password candidates first based on dictionaries and previous password leaks. This is where the factor million (number of accounts N in the Forbes case) comes in. If you want to crack most (easy) passwords, you pick candidate and then try it against each account. Without salt this requires 1 hash calculation, with salt it takes N.

 

[pqr]

epixoip[/url]":lkpsmwbi]

pqr[/url]":lkpsmwbi]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.

If I travel 30 miles in 10 hours, my speed is 3 miles/hour. Knowing the speed I get the distance as 3miles/h * 10 h = 30 miles. Based on the same logic, attempting 3 hashes/account/second means that for 1 milion accounts you need to do 3 million hashes / second. This is the number I originally thought you would call "rate" but it was off by a million so I had to resolve the discrepancy via changing assumptions (taking your result as correct). It just that I changed the wrong ingredient Which was actually helpful reminder that sometimes the discrepancy is simply in the definition of quantity calculated and not in the setup of problem.

 

[ChrisSD]

Jedakiah[/url]":1yf6dc2p]

epixoip[/url]":1yf6dc2p]

Bengie25[/url]":1yf6dc2p]
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.

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.

I think you're over thinking it. If you have a million users each with a unique salt, then you have to crack each and every password individually. So cracking 1M passwords is 1M times slower than cracking one password.

Without unique salts, cracking one password goes at the same speed as cracking a million. That's all.

 

[Whiznot]

Wear boxers and you'll be able to keep people from hacking your briefs.

 

[DougHW]

Control Group[/url]":26yocq4l]

DougHW[/url]":26yocq4l]I love the transparency, but I might not have announced the exact number of iterations. That can't hurt the attackers odds of decrypting them...

Security through obscurity isn't.

You should publish all the details of your security infrastructure - or at least, you should assume that a bad actor already knows every detail of your security infrastructure except for the actual values of any secret tokens involved.

Right, and the number of iterations you use would be considered a secret value that contributes nothing to the validity of the algorithm used. Security through obscurity doesn't mean you should publish your entire security scheme. It means you shouldn't rely on the obscurity to keep you safe.

So using PBKDF2 is good because it relies on proven technology. That doesn't mean you need to let everyone know how many iterations you're using, or your strategy for generating salts. That's not necessary information, and would only aid an attacker.

 

[Bengie25]

epixoip[/url]":19puwtso]

Bengie25[/url]":19puwtso]
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.

I know how salting works. If I was an attacker, and I was going for a specific account, salting would add relatively little overhead to breaking that one account.

With rainbow tables, the individual crack isn't faster, but the group crack is.

This has happened in the past. People get a DB dump, find high profile email addresses and focus on those ones. Salting does not protect much against a focused attacked. Not to mention that rainbow tables only work when people use the same passwords or are using a precomputed lookup.

 

[Goobereater]

Thank you for being open and honest about what has happened. We need more sites to behave in this manner so we (the users) can take appropriate action.

 

[another ars account]

Bengie25[/url]":1xzfbkd2]
I know how salting works. If I was an attacker, and I was going for a specific account, salting would add relatively little overhead to breaking that one account.

Not to disagree with you on this technically, but given that the attacker defaced the site I doubt their intension was a targeted attack against a given account.

On the other hand, if they dump all the account details, other motivated individuals may take that approach.

 

[issor]

ChrisSD[/url]":35w1ccie]

Jedakiah[/url]":35w1ccie]

epixoip[/url]":35w1ccie]

Bengie25[/url]":35w1ccie]
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.

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.

I think you're over thinking it. If you have a million users each with a unique salt, then you have to crack each and every password individually. So cracking 1M passwords is 1M times slower than cracking one password.

Without unique salts, cracking one password goes at the same speed as cracking a million. That's all.

Yeah. You make a password guess, then hash that with the known salt of every entry in your password database (the 1M in this example) and compare. The 3 hashes/sec figure says how many guesses against the whole table are done per sec. Weak/common passwords that are tried first will be cracked.

 

[dillweed81]

Can someone please explain to me how 2048 iterations of MD5 plus a salt supposedly reduces hashes per second to the 3 digits?

I'm looking at the source that was linked:

https://github.com/phpbb/phpbb/blob/pre ... s.php#L585

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.

 

[jonfr]

Changing email address is also something that should be considered. Since those often end up on pay-for-spam list that are sold on the black internet market. I had just updated my email address here due to spam problem from older (different websites) hacks that resulted in me getting tons of spam emails every day.

 

[Control Group]

Andara[/url]":2cw18211]
There comes a point where greater length adds more entropy than expanded character sets. I'm fairly certain that 20 characters is still past that point.

Since greater length increases the exponent, while increased character sets increase the base, that point arrives pretty quickly.

Start with mixed case letters, and a four-character password.

52⁴ = 7,311,616 (10⁶)

Add the digits and 30 specials, and you get

92⁴ = 71,639,296 (10⁷)

Or stick with mixed case letters, and make it a five-character password, and you get

52⁵ = 380,204,032 (10⁸)

/me waits for someone to point out some stupid little error in his arithmetic.

 

[pqr]

dillweed81[/url]":44sm12p4]Can someone please explain to me how 2048 iterations of MD5 plus a salt supposedly reduces hashes per second to the 3 digits?

I'm looking at the source that was linked:

https://github.com/phpbb/phpbb/blob/pre ... s.php#L585

To me this seems like 2048 MD5 operations and 2048 string concatenations. This means the cracking rate should be the time 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.

The numbers provided by Jeremi Gosney (epixoip) on page 5 say 12.2 Ghash/sec pure MD5 rate drops to 3 Mhash/sec which is roughly consistent (~4,000 slowdown). Additional 1 million drop came when you try the same password candidate against all Forbes accounts, i.e., you do rate per account.

 

[dillweed81]

pqr[/url]":2grzbx8j]

dillweed81[/url]":2grzbx8j]Can someone please explain to me how 2048 iterations of MD5 plus a salt supposedly reduces hashes per second to the 3 digits?

I'm looking at the source that was linked:

https://github.com/phpbb/phpbb/blob/pre ... s.php#L585

To me this seems like 2048 MD5 operations and 2048 string concatenations. This means the cracking rate should be the time 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.

The numbers provided by Jeremi Gosney (epixoip) on page 5 say 12.2 Ghash/sec pure MD5 rate drops to 3 Mhash/sec which is roughly consistent (~4,000 slowdown). Additional 1 million drop came when you try the same password candidate against all Forbes accounts, i.e., you do rate per account.

So to understand correctly, what he's saying is "very slow" is not cracking a single hash (which is only 4000x slower than MD5, which is fast when it's 1x) but trying to crack every hash in the database? Also, 4000 makes sense considering the string concatenation in each iteration.

 

[pqr]

dillweed81[/url]":13blnhc9]

pqr[/url]":13blnhc9]

dillweed81[/url]":13blnhc9]Can someone please explain to me how 2048 iterations of MD5 plus a salt supposedly reduces hashes per second to the 3 digits?

I'm looking at the source that was linked:

https://github.com/phpbb/phpbb/blob/pre ... s.php#L585

To me this seems like 2048 MD5 operations and 2048 string concatenations. This means the cracking rate should be the time 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.

The numbers provided by Jeremi Gosney (epixoip) on page 5 say 12.2 Ghash/sec pure MD5 rate drops to 3 Mhash/sec which is roughly consistent (~4,000 slowdown). Additional 1 million drop came when you try the same password candidate against all Forbes accounts, i.e., you do rate per account.

So to understand correctly, what he's saying is "very slow" is not cracking a single hash (which is only 4000x slower than MD5, which is fast when it's 1x) but trying to crack every hash in the database?

Yes. Took a while for me to realize this but it's all sorted out.

 

[235711131719232931]

Bengie25[/url]":1iom8x90]

With rainbow tables, the individual crack isn't faster, but the group crack is.

I think you may be misunderstanding what rainbow tables do: https://en.wikipedia.org/wiki/Rainbow_table. If you have rainbow tables, cracking even a single account is much faster.

 

[Control Group]

DougHW[/url]":1hhvdi30]

Control Group[/url]":1hhvdi30]

DougHW[/url]":1hhvdi30]I love the transparency, but I might not have announced the exact number of iterations. That can't hurt the attackers odds of decrypting them...

Security through obscurity isn't.

You should publish all the details of your security infrastructure - or at least, you should assume that a bad actor already knows every detail of your security infrastructure except for the actual values of any secret tokens involved.

Right, and the number of iterations you use would be considered a secret value that contributes nothing to the validity of the algorithm used. Security through obscurity doesn't mean you should publish your entire security scheme. It means you shouldn't rely on the obscurity to keep you safe.

So using PBKDF2 is good because it relies on proven technology. That doesn't mean you need to let everyone know how many iterations you're using, or your strategy for generating salts. That's not necessary information, and would only aid an attacker.

Sure; I don't actually have anything against not publishing such details. But your scheme must not rely on those details being unknown to be secure. You have to assume that your attacker already knows your iteration count and your salt generation mechanism - because by the time they have your database and can use the information, they also have access to all the systems that do the iterating and salting. The attacker you're worried about - the one who got into your network so thoroughly they've got an offline copy of your DB - is precisely the attacker who can trivially figure out the implementation details you're talking about.

If absolutely nothing else, they can just set up a known account on your system before they make off with the DB, giving them a specific record to attack. With a single target record and a known plaintext, they can reverse engineer any of those details.

 

[styron]

burne_[/url]":1uamhsar]

adfad666[/url]":1uamhsar]My password was dMSXQmpTRfsN3h5HHvEY and I only know that because I just looked it up in Chrome's password manager.

Oddly enough, 'sex and drugs and rock and roll' would have been a better password.

For blockheads maybe.

 

[Marshalrusty]

epixoip did an absolutely excellent job explaining how PHPass works and why it is nothing like a plain md5 hash.

It is a bit shocking how many commenters went from "I have seen md5 mentioned in prior articles a few times" to "I am an expert on cryptography and clearly Ars, phpBB, et al. don't know what they're doing and don't take security seriously." As a matter of fact, we take matters of security extremely seriously. PHPass was chosen because it is a very strong option that works on a wide range of setups. It is certainly getting the job done here with flying colors. If that weren't the case, neither phpBB nor Ars would be using it.

On our newest version, phpBB 3.1, there is support for bcrypt for an even stronger hash. We are more than happy to assist in any way we can to get Ars upgraded in due course.

Yuriy Rusko
Project Manager, phpBB

 

[talon_262]

jonfr[/url]":3c1jkh5x]Changing email address is also something that should be considered. Since those often end up on pay-for-spam list that are sold on the black internet market. I had just updated my email address here due to spam problem from older (different websites) hacks that resulted in me getting tons of spam emails every day.

A lot of people here give Google a lot of shit over many things, some of which is justifiable; however, one thing that, at least in my experience, that Google does very well is spam filtering in Gmail. I almost never, ever have spam emails hit my Gmail inbox, something that I can't say for Comcast, which is why I have Gmail pull my Comcast emails down to give me a unified collection point for all of my emails before i get them into Outlook.

 

[Control Group]

bittermann[/url]"ynfavd2]

Gern Blaanston[/url]"ynfavd2]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.

I agree but you will probably get down voted anyway...such is the Ar's defense force.

It's not some notional "Ars Defense Force," it's reality. There's no such thing as perfect security on the internet; full stop. If you're cloud-facing - which is sort of definitional for a web site - you are vulnerable.

This doesn't mean throw your hands up and do nothing, of course; you take every step you can to make the site as difficult to break into as possible, but it is simply not possible to eliminate the risk. Zero days are found in widespread software with disturbing regularity, and you (definitionally) cannot defend against a true zero day attack.

And that's best case, ignoring the fact that people are in charge of maintaining systems, and people make mistakes. If we fired everyone from every job who ever made a bad security decision, our unemployment rate would be north of 90%. The only sane course is to take precautions consistent with the value of what you're protecting, have proper procedures in place to deal with a breach, and follow those procedures even if it will be embarrassing to the company.

 

[dillweed81]

(Please read my post before blindly downvoting me for taking issue with epixoip's remarks. 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.)

In my opinion he is being misleading, even though he's correct.

I work in infosec and have participated in some red team exercises. My personal fear in these scenarios is not the entire database being cracked, it's a targeted attacker who singles me out and dedicates boxes to doing nothing but trying to crack just my account's password hash. This is an extremely common tactic used by black hats and by white hat pentesters.

Scrypt or bcrypt would mitigate this much more than iterated MD5, unless the iterations are closer to what the industry recommends. OWASP's recommendations for PBKDF2 are 128,000 iterations in 2014, and that's also recommending SHA1 or SHA-256, not MD5. If you compare SHA1's speed with MD5, I would guess that 150k or 200k would be the recommendation for MD5 (it is easy to calculate the exact number if someone wants to). 150,000 is a lot higher than 2,048.

Sure, the vast majority of users here probably will never be targeted in such a way, but undoubtedly at least a few will be. PHPass is certainly much better than just salted single-round MD5, but it's not good either.

The only numbers epixoip gave were how hard it would be to crack the entire data set containing every Ars account. Ars has a ton of users and each hash is salted, so obviously this would take a long time, and would take a far longer time than it would take if the algorithm was merely a single md5($salt . $password). But it is still not very secure for the reasons I listed above. Most people are (probably) going to be safe sheerly because they're a needle in a large haystack, not because the hash is strong.

Marshalrusty[/url]":u6nqhglw]epixoip did an absolutely excellent job explaining how PHPass works and why it is nothing like a plain md5 hash.

It is a bit shocking how many commenters went from "I have seen md5 mentioned in prior articles a few times" to "I am an expert on cryptography and clearly Ars, phpBB, etc. don't know what they're doing and don't take security seriously." As a matter of fact, we take matters of security extremely seriously. PHPass was chosen because it is a strong choice that works on a wide range of setups. It is certainly going to get the job done here. On our newest version, phpBB 3.1, there is support for bcrypt for an even stronger hash.

Yuriy Rusko
Project Manager, phpBB

Sorry, but just because the function has a fancy name does not mean it is magically good.

The source code is right here:

https://github.com/phpbb/phpbb/blob/pre ... s.php#L585

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

 

[dillweed81]

drukov[/url]":2n9hec9z]

epixoip[/url]":2n9hec9z]

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.

Regardless, my password has at least 64 bits of entropy according to KeePass. And typing this into google reveals: (2^64 / 3 million) seconds = 194852 years.

Overall, you are correct, just that comment about salting is bizarre.

Read my post above. His comment about salting is weird until you understand he's talking about the effort required to crack the entire dataset. Obviously it does nothing when you look at it on a user-by-user basis.

 

[CppThis]

Obligatory 'they obviously had it coming for insufficient internet-security theater' reply.

Anyway, thanks for the update and details on what they did--it's nice to see a site own up to it instead of pretend it never happened. I went ahead and changed PW, though my risk is pretty low given that CppThis is just the name I use for being a huge flaming asshole on comment sites--nothing financial/real PII/etc.

 

[pqr]

dillweed81[/url]":zhc44wvy](Please read my post before blindly downvoting me for taking issue with epixoip's remarks. 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.)

In my opinion he is being misleading, even though he's correct.

I work in infosec and have participated in some red team exercises. My personal fear in these scenarios is not the entire database being cracked, it's a targeted attacker who singles me out and dedicates boxes to doing nothing but trying to crack just my account's password hash. This is an extremely common tactic used by black hats and by white hat pentesters.

Scrypt or bcrypt would mitigate this much more than iterated MD5, unless the iterations are closer to what the industry recommends. OWASP's recommendations for PBKDF2 are 128,000 iterations in 2014, and that's also recommending SHA1 or SHA-256, not MD5. If you compare SHA1's speed with MD5, I would guess that 150k or 200k would be the recommendation for MD5 (it is easy to calculate the exact number if someone wants to). 150,000 is a lot higher than 2,048.

Sure, the vast majority of users here probably will never be targeted in such a way, but undoubtedly at least a few will be. PHPass is certainly much better than just salted single-round MD5, but it's not good either.

The only numbers epixoip gave were how hard it would be to crack the entire data set containing every Ars account. Ars has a ton of users and each hash is salted, so obviously this would take a long time, and would take a far longer time than it would take if the algorithm was merely a single md5($salt . $password). But it is still not very secure for the reasons I listed above. Most people are (probably) going to be safe sheerly because they're a needle in a large haystack, not because the hash is strong.

Marshalrusty[/url]":zhc44wvy]epixoip did an absolutely excellent job explaining how PHPass works and why it is nothing like a plain md5 hash.

It is a bit shocking how many commenters went from "I have seen md5 mentioned in prior articles a few times" to "I am an expert on cryptography and clearly Ars, phpBB, etc. don't know what they're doing and don't take security seriously." As a matter of fact, we take matters of security extremely seriously. PHPass was chosen because it is a strong choice that works on a wide range of setups. It is certainly going to get the job done here. On our newest version, phpBB 3.1, there is support for bcrypt for an even stronger hash.

Yuriy Rusko
Project Manager, phpBB

Sorry, but just because the function has a fancy name does not mean it is magically good.

The source code is right here:

https://github.com/phpbb/phpbb/blob/pre ... s.php#L585

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

Do you have link to reasoning behind those standards? For 12-character alphanumeric password, still takes half million years to try all combination with 350 GIGAhash/sec raw MD5 rate (meaning ~150 Mhash/sec for 2048x MD5, actually more like 75 Mhash/sec in practice with HashCat). I would consider that safe enough for the moment...

 

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

 

[bittermann]

Control Group[/url]":1qpffblj]

bittermann[/url]":1qpffblj]

Gern Blaanston[/url]":1qpffblj]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.

I agree but you will probably get down voted anyway...such is the Ar's defense force.

It's not some notional "Ars Defense Force," it's reality. There's no such thing as perfect security on the internet; full stop. If you're cloud-facing - which is sort of definitional for a web site - you are vulnerable.

This doesn't mean throw your hands up and do nothing, of course; you take every step you can to make the site as difficult to break into as possible, but it is simply not possible to eliminate the risk. Zero days are found in widespread software with disturbing regularity, and you (definitionally) cannot defend against a true zero day attack.

And that's best case, ignoring the fact that people are in charge of maintaining systems, and people make mistakes. If we fired everyone from every job who ever made a bad security decision, our unemployment rate would be north of 90%. The only sane course is to take precautions consistent with the value of what you're protecting, have proper procedures in place to deal with a breach, and follow those procedures even if it will be embarrassing to the company.

I don't recall anybody asking someone to get fired. Hyperbole much? Anybody can get hacked with a zero day exploit but I don't think this was one of them. Practice what you preach and be a little more diligent with security. Is that to much to ask from all you experts? Getting tired of changing online passwords this year because of; "insert reason here". If this is the new norm it sucks. Down vote away..

 

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

 

[Control Group]

bittermann[/url]":2ihafhla]

Control Group[/url]":2ihafhla]

bittermann[/url]":2ihafhla]

Gern Blaanston[/url]":2ihafhla]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.

I agree but you will probably get down voted anyway...such is the Ar's defense force.

It's not some notional "Ars Defense Force," it's reality. There's no such thing as perfect security on the internet; full stop. If you're cloud-facing - which is sort of definitional for a web site - you are vulnerable.

This doesn't mean throw your hands up and do nothing, of course; you take every step you can to make the site as difficult to break into as possible, but it is simply not possible to eliminate the risk. Zero days are found in widespread software with disturbing regularity, and you (definitionally) cannot defend against a true zero day attack.

And that's best case, ignoring the fact that people are in charge of maintaining systems, and people make mistakes. If we fired everyone from every job who ever made a bad security decision, our unemployment rate would be north of 90%. The only sane course is to take precautions consistent with the value of what you're protecting, have proper procedures in place to deal with a breach, and follow those procedures even if it will be embarrassing to the company.

I don't recall anybody asking someone to get fired. Hyperbole much? Anybody can get hacked with a zero day exploit but I don't think this was one of them. Practice what you preach and be a little more diligent with security. Is that to much to ask from all you experts? Getting tired of changing online passwords this year because of; "insert reason here". If this is the new norm it sucks. Down vote away..

If your metric for "more diligent with security" is "didn't get hacked," then yes. It's like asking for an uncrashable airplane, impregnable vault, or inescapable prison. No such animal. And every incremental step towards unattainable perfection costs exponentially more than the last. At some point, simple math dictates you have to stop and accept a level of risk.

For the FAA, for example, that number is (IIRC) 1 death per hundred thousand flight hours.

You can see this logic at work in your own life if you invert the question. If you wanted to achieve perfect online security, you'd simply not have an online presence. Job done. But that cost is too high for you to bear, so you risk being hacked in order to reap the rewards of participating in the internet.

 

[dillweed81]

pqr[/url]":4rwp78br]

dillweed81[/url]":4rwp78br](Please read my post before blindly downvoting me for taking issue with epixoip's remarks. 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.)

In my opinion he is being misleading, even though he's correct.

I work in infosec and have participated in some red team exercises. My personal fear in these scenarios is not the entire database being cracked, it's a targeted attacker who singles me out and dedicates boxes to doing nothing but trying to crack just my account's password hash. This is an extremely common tactic used by black hats and by white hat pentesters.

Scrypt or bcrypt would mitigate this much more than iterated MD5, unless the iterations are closer to what the industry recommends. OWASP's recommendations for PBKDF2 are 128,000 iterations in 2014, and that's also recommending SHA1 or SHA-256, not MD5. If you compare SHA1's speed with MD5, I would guess that 150k or 200k would be the recommendation for MD5 (it is easy to calculate the exact number if someone wants to). 150,000 is a lot higher than 2,048.

Sure, the vast majority of users here probably will never be targeted in such a way, but undoubtedly at least a few will be. PHPass is certainly much better than just salted single-round MD5, but it's not good either.

The only numbers epixoip gave were how hard it would be to crack the entire data set containing every Ars account. Ars has a ton of users and each hash is salted, so obviously this would take a long time, and would take a far longer time than it would take if the algorithm was merely a single md5($salt . $password). But it is still not very secure for the reasons I listed above. Most people are (probably) going to be safe sheerly because they're a needle in a large haystack, not because the hash is strong.

Marshalrusty[/url]":4rwp78br]epixoip did an absolutely excellent job explaining how PHPass works and why it is nothing like a plain md5 hash.

It is a bit shocking how many commenters went from "I have seen md5 mentioned in prior articles a few times" to "I am an expert on cryptography and clearly Ars, phpBB, etc. don't know what they're doing and don't take security seriously." As a matter of fact, we take matters of security extremely seriously. PHPass was chosen because it is a strong choice that works on a wide range of setups. It is certainly going to get the job done here. On our newest version, phpBB 3.1, there is support for bcrypt for an even stronger hash.

Yuriy Rusko
Project Manager, phpBB

Sorry, but just because the function has a fancy name does not mean it is magically good.

The source code is right here:

https://github.com/phpbb/phpbb/blob/pre ... s.php#L585

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

Do you have link to reasoning behind those standards? For 12-character alphanumeric password, still takes half million years to try all combination with 350 GIGAhash/sec raw MD5 rate (meaning ~150 Mhash/sec for 2048x MD5, actually more like 75 Mhash/sec in practice with HashCat). I would consider that safe enough for the moment...

As I'm sure epixoip can explain, full alphanumeric bruteforcing is usually a last resort; it's not fair to use just the entropy as the cracking difficulty. I would recommend taking a look at all the attack types listed on HashCat's wiki: https://hashcat.net/wiki/

A 12-character password will still end up being pretty strong, unless it's just a dictionary word or multiple dictionary words or some easy permutation of either of those. You'll likely find that even on a tech site like Ars, though, a great deal many people will have passwords that are 8 or fewer characters long.

 

[True_North]

epixoip[/url]":1k0yeorq]

Jedakiah[/url]":1k0yeorq]

epixoip[/url]":1k0yeorq]
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.

Thank You for the simplified explanation! Even for a jarhead like me i can comprehend this.

 

[bittermann]

Control Group[/url]":15z106qa]

bittermann[/url]":15z106qa]

Control Group[/url]":15z106qa]

bittermann[/url]":15z106qa]

Gern Blaanston[/url]":15z106qa]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.

I agree but you will probably get down voted anyway...such is the Ar's defense force.

It's not some notional "Ars Defense Force," it's reality. There's no such thing as perfect security on the internet; full stop. If you're cloud-facing - which is sort of definitional for a web site - you are vulnerable.

This doesn't mean throw your hands up and do nothing, of course; you take every step you can to make the site as difficult to break into as possible, but it is simply not possible to eliminate the risk. Zero days are found in widespread software with disturbing regularity, and you (definitionally) cannot defend against a true zero day attack.

And that's best case, ignoring the fact that people are in charge of maintaining systems, and people make mistakes. If we fired everyone from every job who ever made a bad security decision, our unemployment rate would be north of 90%. The only sane course is to take precautions consistent with the value of what you're protecting, have proper procedures in place to deal with a breach, and follow those procedures even if it will be embarrassing to the company.

I don't recall anybody asking someone to get fired. Hyperbole much? Anybody can get hacked with a zero day exploit but I don't think this was one of them. Practice what you preach and be a little more diligent with security. Is that to much to ask from all you experts? Getting tired of changing online passwords this year because of; "insert reason here". If this is the new norm it sucks. Down vote away..

If your metric for "more diligent with security" is "didn't get hacked," then yes. It's like asking for an uncrashable airplane, impregnable vault, or inescapable prison. No such animal. And every incremental step towards unattainable perfection costs exponentially more than the last. At some point, simple math dictates you have to stop and accept a level of risk.

For the FAA, for example, that number is (IIRC) 1 death per hundred thousand flight hours.

You can see this logic at work in your own life if you invert the question. If you wanted to achieve perfect online security, you'd simply not have an online presence. Job done. But that cost is too high for you to bear, so you risk being hacked in order to reap the rewards of participating in the internet.

More hyperbole...apparently asking for more due diligence is unobtainable. Got it.

 

[dimhue]

dillweed81[/url]":kbqtuwhm](Please read my post before blindly downvoting me for taking issue with epixoip's remarks. 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.)

<snip>

You're talking about an edge case of an edge case for a website like Ars Technica. The vast majority (if not literally all) don't need to be concerned with a specific targeted attack against them. Ars' system is adequate for untargeted attacks, and that's what most users should be worried about.

 

[pqr]

dillweed81[/url]":cw7m1cnw]

pqr[/url]":cw7m1cnw]

dillweed81[/url]":cw7m1cnw](Please read my post before blindly downvoting me for taking issue with epixoip's remarks. 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.)

In my opinion he is being misleading, even though he's correct.

I work in infosec and have participated in some red team exercises. My personal fear in these scenarios is not the entire database being cracked, it's a targeted attacker who singles me out and dedicates boxes to doing nothing but trying to crack just my account's password hash. This is an extremely common tactic used by black hats and by white hat pentesters.

Scrypt or bcrypt would mitigate this much more than iterated MD5, unless the iterations are closer to what the industry recommends. OWASP's recommendations for PBKDF2 are 128,000 iterations in 2014, and that's also recommending SHA1 or SHA-256, not MD5. If you compare SHA1's speed with MD5, I would guess that 150k or 200k would be the recommendation for MD5 (it is easy to calculate the exact number if someone wants to). 150,000 is a lot higher than 2,048.

Sure, the vast majority of users here probably will never be targeted in such a way, but undoubtedly at least a few will be. PHPass is certainly much better than just salted single-round MD5, but it's not good either.

The only numbers epixoip gave were how hard it would be to crack the entire data set containing every Ars account. Ars has a ton of users and each hash is salted, so obviously this would take a long time, and would take a far longer time than it would take if the algorithm was merely a single md5($salt . $password). But it is still not very secure for the reasons I listed above. Most people are (probably) going to be safe sheerly because they're a needle in a large haystack, not because the hash is strong.

Marshalrusty[/url]":cw7m1cnw]epixoip did an absolutely excellent job explaining how PHPass works and why it is nothing like a plain md5 hash.

It is a bit shocking how many commenters went from "I have seen md5 mentioned in prior articles a few times" to "I am an expert on cryptography and clearly Ars, phpBB, etc. don't know what they're doing and don't take security seriously." As a matter of fact, we take matters of security extremely seriously. PHPass was chosen because it is a strong choice that works on a wide range of setups. It is certainly going to get the job done here. On our newest version, phpBB 3.1, there is support for bcrypt for an even stronger hash.

Yuriy Rusko
Project Manager, phpBB

Sorry, but just because the function has a fancy name does not mean it is magically good.

The source code is right here:

https://github.com/phpbb/phpbb/blob/pre ... s.php#L585

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

Do you have link to reasoning behind those standards? For 12-character alphanumeric password, still takes half million years to try all combination with 350 GIGAhash/sec raw MD5 rate (meaning ~150 Mhash/sec for 2048x MD5, actually more like 75 Mhash/sec in practice with HashCat). I would consider that safe enough for the moment...

As I'm sure epixoip can explain, full alphanumeric bruteforcing is usually a last resort; it's not fair to use just the entropy as the cracking difficulty. I would recommend taking a look at all the attack types listed on HashCat's wiki: https://hashcat.net/wiki/

A 12-character password will still end up being pretty strong, unless it's just a dictionary word or multiple dictionary words or some easy permutation of either of those. You'll likely find that even on a tech site like Ars, though, a great deal many people will have passwords that are 8 or fewer characters long.

So those industry recommendations are for people unlike me. Fine then I need not really care. But if you can point to flaw or weak assumption in my time estimate I very much would like to hear...

 

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

 

[logic_88]

dillweed81[/url]":4ws0r64h]
A 12-character password will still end up being pretty strong, unless it's just a dictionary word or multiple dictionary words or some easy permutation of either of those. You'll likely find that even on a tech site like Ars, though, a great deal many people will have passwords that are 8 or fewer characters long.

Does it matter if I use a strong password or not for Ars?

Aside from an email address, I don't have any personal information stored here.

 

[rdx]

dillweed81[/url]":20x2d836](Please read my post before blindly downvoting me for taking issue with epixoip's remarks. 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.)

In my opinion he is being misleading, even though he's correct.

I work in infosec and have participated in some red team exercises. My personal fear in these scenarios is not the entire database being cracked, it's a targeted attacker who singles me out and dedicates boxes to doing nothing but trying to crack just my account's password hash. This is an extremely common tactic used by black hats and by white hat pentesters.

Scrypt or bcrypt would mitigate this much more than iterated MD5, unless the iterations are closer to what the industry recommends. OWASP's recommendations for PBKDF2 are 128,000 iterations in 2014, and that's also recommending SHA1 or SHA-256, not MD5. If you compare SHA1's speed with MD5, I would guess that 150k or 200k would be the recommendation for MD5 (it is easy to calculate the exact number if someone wants to). 150,000 is a lot higher than 2,048.

Sure, the vast majority of users here probably will never be targeted in such a way, but undoubtedly at least a few will be. PHPass is certainly much better than just salted single-round MD5, but it's not good either.

The only numbers epixoip gave were how hard it would be to crack the entire data set containing every Ars account. Ars has a ton of users and each hash is salted, so obviously this would take a long time, and would take a far longer time than it would take if the algorithm was merely a single md5($salt . $password). But it is still not very secure for the reasons I listed above. Most people are (probably) going to be safe sheerly because they're a needle in a large haystack, not because the hash is strong.

Marshalrusty[/url]":20x2d836]epixoip did an absolutely excellent job explaining how PHPass works and why it is nothing like a plain md5 hash.

It is a bit shocking how many commenters went from "I have seen md5 mentioned in prior articles a few times" to "I am an expert on cryptography and clearly Ars, phpBB, etc. don't know what they're doing and don't take security seriously." As a matter of fact, we take matters of security extremely seriously. PHPass was chosen because it is a strong choice that works on a wide range of setups. It is certainly going to get the job done here. On our newest version, phpBB 3.1, there is support for bcrypt for an even stronger hash.

Yuriy Rusko
Project Manager, phpBB

Sorry, but just because the function has a fancy name does not mean it is magically good.

The source code is right here:

https://github.com/phpbb/phpbb/blob/pre ... s.php#L585

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

Unless your threat model for Ars is someone exfiltrating the passwords DB and working on some extremely worthy target hash for month(s) unnoticed, this doesn't make much sense.

12 character lower-case random password would already take 50 years on a rig like this, and simply throwing in digits would raise that to 2000 years. I'd think most passwords would expire by then. A state-level resourceful actor with a thousand of those rigs *could* extract all lowercase 12 character pass in possibly meaningful period - and would be defeated by switching to full ASCII random.

This only gives a little grace period for extremely weak passwords on the order of 8 [0-9a-z] random characters. Dictionary crackable passwords wouldn't profit from this at all, as moving from seconds/hours to minutes/day won't help in this case.