MD5 is an utterly terrible password hash. It's just about as bad as plaintext. If you're hashing passwords with md5, please fix it and use one of scrypt, bcrypt or PBKDF2 (recommendations are generally in that order) with an acceptable load factor[0]. Go look up mozilla's coding security guide to know how to migrate from a terrible and insecure hash to a secure password hash.
[0] the usual suggestion is that hashing a password should take a few hundred milliseconds on the production hardware, ideally at least half a second and really as much as your users will accept. For scrypt's memory load factor, it should take as much as you can spare.
Hyperbole is just about as bad as murder.
It's not hyperbole, a rainbow table will give you instant plaintext for 95% of your passwords. And even if you don't want to use one, an off-the-shelf high-end graphic card (~$500) can compute 10 billion md5 hashes per second, plug that in a not-completely-retarded brute-forcer (jack the ripper, oclhashcat) and you've got pretty much the whole database as plaintext in hours tops.
The only passwords you won't have plaintexted are those so complex you know the user doesn't reuse them anyway.
155a7a01308fa0807f722c5984bd91fb
---
I find "high-end graphic card (~$500) can compute 10 billion md5 hashes per second" a bit unbelievable [but that's progress for ya]. So that's roughly all possible alphanum characters of stringlen 6, each second.
So if my calculation is correct (assuming 60 alphanum chars randomly chosen) that's only 7000 years to calculate all 12 char strings?
Yes I realise that md5'ed password strings aren't random nor usually particularly long. Just saying.
You may want to read the last phrase of my comment.
> I find "high-end graphic card (~$500) can compute 10 billion md5 hashes per second" a bit unbelievable
And yet those are the numbers oclhashcat lite publishes for 0.10 on a stock Radeon HD6990 (10886.3M c/s): http://hashcat.net/oclhashcat-lite/
> Yes I realise that md5'ed password strings aren't random
Which is the whole point, and the knowledge the tools I mentioned use: https://community.qualys.com/blogs/securitylabs/2012/06/08/l... (note: the article is about sha1 hashes — which are about 3 times as expensive to compute as md5 — and is done on an older CPU, not GPU-assisted hashing)
> Just saying.
Just saying absolutely nothing?
"a bit unbelievable [but that's progress for ya]"
In case you're comprehension is masked in some way the meaning of this is "it's hard to believe that this is possible [with such stock hardware] but I recognise that technological progress has brought us to a point where this is possible; tech progress can surprise one in this sort of manner" - obviously I felt that such verbosity wasn't required.
>Just saying absolutely nothing? //
So what's the plaintext of that hash I posted?
So you don't think that 'md5 is only as difficult to read as plaintext is actually hyperbole'?
If this is the case then surely someone has a plaintext for the hash I wrote - how much more real can one get. It's a simple English language password.
It is not reliable cryptography, and if you provide an incentive to reverse that hash (rather than merely challenging people who have better things to do) then it will be reversed. When it comes to the type of enterprise which cracks systems for profit, it is as good as plaintext.
I don't doubt it could be reversed relatively easily. It doesn't appear to be in the online rainbow tables I tried. But having to look something up, have domain knowledge, making multiple computations, program a parallelised attack using GPUs or however one approaches such a problem I still contend it's significantly (though not greatly) better than plaintext.
At the highest level, you're missing the issue of specialization and parallelization.
This misunderstanding is partly alluded to by your surprise at the power of GPUs to hash passwords. GPUs can have hundreds or even thousands of what you might think of as "cores", but they're very specialized cores that are only suited to certain kinds of operations. Those operations were originally intended for the problem domain of high-performance graphics, but as it happens, many of those same operations mesh very well with cryptographic hashes. In essence, we've all got specialized massively-parallel password-cracking supercomputers sitting on our desks.
Take this up a level, and you might see the most obvious implication: More $500 graphics cards, more passwords cracked in a given timeframe. Very naïvely speaking, 7,000 $500 graphics cards, $3.5 million. You've just gained the ability to hash every one of those 12-character strings in one year for the cost of a funding round. Oops.
Relatedly, you're talking about cracking a password. That's wrong. Nobody cares about cracking your password, or my password. They're going after passwords, in a massively plural sense.
Start with 100,000 md5 password hashes. Assume the passwords are all 12 characters (they're not) and they're randomly generated (again, not). You don't conduct a brute-force search for every hash, you conduct a brute force search for 100,000 hashes. 7,000 years divided by 100,000 hashes is 25.55 days. With a $500 graphics card, the crackers can brute-force a password every month.
Now, once you realize that the entropy in the average password is not even within an order of magnitude of 60^12, you might begin to see the problem. You'd be lucky to find a password that's 36^8.
That purported 7,000 years is starting to look a lot smaller, isn't it?
This is why we have things like bcrypt and PBKDF2.
This only works if hash reversal costs the same as hash calculation. I think you've made an error.
Brute force in hash terms doesn't mean a "search" it means you take a string, hash it and see if the hash matches. That's the brute part, no grace.
The 7000 years figure is clearly vastly inflated what's needed for passwords in the wild but I'm merely countering the contention that 'md5 is as good as plaintext'.
I note that despite it apparently only taking seconds to reverse my short string that no one has posted the plaintext yet. This doesn't look like it is as easy to read as plaintext.
I'm not at all claiming md5 is good security - just suggesting that the claim that md5 is equivalent to plaintext is hyperbole.
The easy way to show that I'm wrong is to post the plaintext of that hash.
A) That is a search, and B) I know this. You are still fundamentally misunderstanding the problem domain. We don't care about a hash. We care about 100,000 hashes. You don't need to brute force every single hash from scratch, you simply have to take a string, hash it, and see if that hash is present in the table of 100,000 hashes.
> I note that despite it apparently only taking seconds to reverse
No one claimed that, you inferred it based on a fundamental misunderstanding of the problem domain.
Ha ha. Not really. You're not searching for the plaintext that produces a hash. You're producing hashes irrespective of the result and then matching. IMO the term search would only truly apply if you were reversing the hash mathematically - you'd start with the hash and perform a non-complex operation to find the plaintext.
Instead one searches across hashes after compiling a correspondence table, not across plaintexts. I suppose it's a subtle distinction; largely irrelevant to my contention.
>you inferred it based on a fundamental misunderstanding of the problem domain //
I did not infer it. It was implied. For example,
emidln: "md5 passwords lists are plaintext for modern hardware"
So yes, I suppose adding on a few seconds for plaintext recovery was unfair of me, based on a comment like this I should have said "I note that despite just having to read it back almost as quickly as plaintext ...".
WRT the problem domain. You're discussing an entirely different issue to that which I raised. The start point is simply this:
>"MD5 is an utterly terrible password hash. It's just about as bad as plaintext." //
That is the pertinent problem domain for my comment. I even went to efforts to emphasise that beyond that atomic claim I was recognising the paucity of md5 for real world password hashing - I don't think one can have used Rainbow tables and not realised that point. Are you really contending still that md5 is almost equivalent to plaintext in terms of string discovery and that there is no exaggeration in that.
If the IEEE logs were released with md5 hashed passcodes then other than trivial recognisable cases like 2867-whatever-it-is then one at least has to do work to recover the plaintext.
Aside: I'm intrigued why you created a separate account just to press this position.
A simple MD5 hash is "about as bad as plaintext" because the vast majority of passwords will be trivially cracked if it's used, not because any one password will be cracked in a trivial timeframe.
masklinn was speaking against this background. You've created a whole other background that just isn't relevant to the real world issue of password hashing.
> Aside: I'm intrigued why you created a separate account just to press this position.
I created an account so I'd have one to respond to your comment with. The choice of name does not mean it's specific to this discussion, it was simply inspired by it. Again, you focus on an individual detail to the detriment of the big picture.
Ostensibly the difference here is that you're looking from the administrative side (it appears) and I'm looking from the user's side.
As for "again". Surely using your regular account makes for a bigger picture as I could see where you're coming from, your general demeanour, your desire to argue incessantly around the point whilst not broaching the point itself, that sort of thing. From your side the choice of name as specific may well be "the big picture" but from anyone else reading the discussion you've removed a lot of out-of-band information that could be pertinent. Which to be honest makes me chuckle as you accuse me, probably rightly in this instance, of narrow focus.
>A simple MD5 hash is "about as bad as plaintext" because the vast majority of passwords will be trivially cracked if it's used //
With plaintext all passwords will be "cracked" in zero time. With MD5 good passwords will be expensive to crack. ROT-13 is about as bad as plaintext. MD5 IMO is better to a point that this claim was exaggeration.
So we'll go straight to the rub - you disagree that there was any exaggeration in that initial statement?
From the user's side, proper password storage practices mean your passwords are far less likely to be compromised.
> Surely using your regular account
Uh, and what "regular account" would that be? You assume much, but know little.
> you disagree that there was any exaggeration in that initial statement?
Yes.
Indeed and considering I'm using 20 char mixed passkeys if they're hashed with md5 then they'll take zillions of times longer to reveal than plaintext ... oh wait, no they won't because plaintext is about as bad as plaintext - and you appear to believe that is from any perspective ...
So go on, 3 days must be plenty of time to read something that's about as bad as plaintext at remaining unread.
>You assume much, but know little. //
There is nothing certain, not even this. However pyrhonic absolutism gives sway to pragmatism in general conversation.
So, what, never post on HN, create a new account for each thread, enter comments direct to the db using a morse key ... what? I'd hardly call the assumption that you had an account that you used in the normal way to be massive.
Looks like they were processing the logins using GET instead of POST, unaware it was logging all the requests. Then the log files ended up on an ftp server for anyone to download.
The IEEE is an association, and doesn't actually have any engineers working for it. Likely, their website is outsourced to one of the local web development firms in town.
They've sent me my cleartext password several times before I finally wrote it down in a place I could keep it safe, and I was always thankful.
Also, the default password is something very simple per account. I don't want to go into any more detail on that.
yes, it very much is.
> In most cases what someone could do with my account is to view articles I have paid for
That's not the problem with leaking plaintext accounts. If the user database is compromised, you can safely assume all of the site is and the site's data is leaked as well (or would be if anyone gave a fuck).
The problem of cleatext (or easy to reverse) password databases is twofold:
1. Most users reuse the same password again and again and again. Having their password leaked on site 1 means all of their accounts are now wide open to whoever got the passwords.
2. Even if only the passwords themselves are leaked, this provides a huge dataset of effective, real-world password. This is a treasure trove of human behaviors and enables the improvement of brute-forcing mutators. In fact, one of the most substantial and important events in modern hacking history was the RockYou password leak.
Yes it is generally accepted that many users reuse the same password on different sites. But that is a separate issue and really has nothing to do with what has happened here or why proper security should obviously be followed. Not disagreeing with that.
But I disagree with the fact that since the user does the wrong thing many times, it is the responsibility of the site operator to assume that in the building of their product (in the way this issue is being discussed). If it is, where are all the warnings on any site saying "make sure not to give us a password you use anywhere else". (I've rarely seen any warning like that, have you?)
Of course this is all a matter of degree. There are many cases where you have to prevent users from their folly. True. My question is simply while there are many ways that sites try to enforce correct password behavior, I've yet to see (meaning if it exists I haven't really noticed it whereas I've notice other password thoughts) one that informs people to make sure the password they use is unique to their site AND the other typical restrictions (length, mixed case etc.)
No. That's the one and whole reason why you're supposed to one-way encrypt passwords with a suitable hash: protecting the shared secret.
> But I disagree
So what?
> If it is, where are all the warnings on any site saying "make sure not to give us a password you use anywhere else". (I've rarely seen any warning like that, have you?)
Yes, I have. These warnings don't actually add to anything as they're not followed, and impossible to get followed without making the system so cumbersome it's unusable. Apart from using 2-factor auth. Which is an other "responsibility of the site operator" which I guess you wouldn't want foisted upon him as you seem to believe site operators are and should be irresponsible.
> one that informs people to make sure the password they use is unique to their site
A suggestion which will go instantly ignored by 99% of the users (on average, technical sites will probably be lower). The single % left already don't reuse passwords.
It was plainly obvious to any user of IEEE that they were storing your password in clear text. Because they would, y'know, mail it to you. And the mail would have live hyperlinks to access your account, which generally means GET requests.
Which isn't really relevant. A password leak is a password leak, whatever its source is.
> It was plainly obvious to any user of IEEE that they were storing your password in clear text
And nobody every took issue with that?
> And the mail would have live hyperlinks to access your account, which generally means GET requests.
That doesn't mean anything, the hyperlink could have contained a nonce allowing log-in.
Then please don't bring it up, i.e., say things like "if the user database is compromised, you can safely assume all of the site is".
And nobody every took issue with that?
Maybe they did, maybe they didn't. IEEE members are probably slightly more informed than your random AOL user. There are plenty of mail managers out there that mail you your password automatically every month.
The user database was compromised in a major way, even if nobody got root.
If so, it should be quite interesting if someone uses the IEEE Web Account username/password to re-forward your @ieee.org e-mail somewhere else. I can see all sorts of nefarious activities that can result from this, such as clicking on various "I forgot my password" links that also use your @ieee account in order to get access to other, perhaps more important resources.
given that people signed up using corporate email addresses, this could be used to hack internal networks of companies.
So I think the onus of responsibility lies with corp IT and not HR.
There's no technical solution to this problem. In the end it comes down to making people actually memorize pseudorandom passwords. As long as there's no shoulder surfing or keyloggers, you can keep such a password for years.
Nice work!
FuC|Kj0017GUy-1 FuC|Kj0017GUy-2 FuC|Kj0017GUy-3
Or, for users who are lazier (read: most of them), you get:
S3P-2k12 0c7-2k12 n0V-2k12