On this submission? Come on. You obviously grasp that some submissions are lighter-hearted than others, otherwise you wouldn't have left http://news.ycombinator.com/item?id=2307252 on the mspaint.exe expressed as PCM item.
Since you edited out "be useful or go elsewhere," I know that you're thinking your orders to us are a bit across the line, too. They are. Might as well finish it off and edit them all the way out.
Now, on to your URL:
I've tired of people mindlessly chirping the bcrypt approach for storing passwords, particularly that very blog post, when really there is absolutely nothing wrong with hashing. This line particularly irks me, amongst others:
> Salt or no, if you’re using a general-purpose hash function designed for speed you’re well and truly effed.
The author glosses right over keeping a separate salt (shared secret) outside of the database itself, so that you need two separate compromises -- application code and database -- in order to retrieve plaintext passwords. He also claims that "salts won't help you" plain text full stop, without justifying that remark well in the article, and completely avoiding their utility at preventing a rainbow attack.
Instead, the entire article resorts to fear mongering, and I'm tired of people citing it. I will continue using hashing, and watch as the Anonymous groups and so on pick off the low-hanging fruit.
If you mindlessly copy and paste that URL to me without fully and objectively understanding the implications of what you're implementing, and why bcrypt might not be right for you, you really should step back and rethink your decision. In particular, if your app is handling a lot of logins, you're going to become CPU bound extremely quickly. Using the author's benchmark of 0.3 seconds for a simple password hash, how many simultaneous login attempts do you think it's going to take to saturate a core?
I agree you that this article has nothing to do with salting, and I don't know why the grandparent comment was even made, but there are a few points I would like to make about what you've said.
> when really there is absolutely nothing wrong with hashing.
Hashing is millions of times better than storing the plaintext. Adding a salt probably increases the workload by about as much as going from salted hash to bcrypt [constant time lookup in rainbow table -> exponential time in length of password -> higher constant factor exponential time]. But I must disagree with you saying there's nothing wrong with hashing, however. There is something wrong with hashing, and that is that it's possible to brute force many passwords. However you're perfectly right that going hash+salt to bcrypt doesn't do nearly as much as going from plaintext to hash+salt.
And you're also right in that the simple passwords will fall anyways. You could have it take 30 seconds per password and an attacker could still get the passwords a couple percent of your users (who picked '123456', 'password', etc). If I pick '$yN3,A%2vq{-', no matter if the server is using MD5-crypt or even scrypt, you won't be getting my password.
> you're going to become CPU bound extremely quickly
This is one of the only valid criticisms of bcrypt, and it is a significant one. One of the nice things about it, though, is you don't have to use the 0.3 second time. That's just chosen arbitrarily. If you think that's too high, then go with 0.03 seconds, or 0.003 seconds. Surely you can deal with that requirement. Granted, brute forcing is now 1000 times faster -- but hey, it's 1000 times slower than bruteforcing a hash.
Anyhow, I don't disagree with most of what you're saying. I just wanted to point out that it's still possible to go with bcrypt by just decreasing the workload to a reasonable level for your application; I'm not trying to say you're wrong.
Okay, yes. By 'hash', I meant generic, general purpose hashing function. MD5. SHA-1. SHA-2. SHA-3 (any of the finalists). Anything that is fast enough that you would use it to compute a cryptographically secure checksum of a large block of data.
Your comment and descendants are the only ones of value on this submission, along with one other comment from Stormbringer. Mine was a desperate attempt to provide some kind of substance before the comments descended into the jokes and one-liners that now fill the page. (I'm surprised hunter2 hasn't been mentioned yet).
The MSPaint submission was clearly a bit of fun. Password security isn't.
I felt in this case that the comments that were being made sent the wrong message about what HN strives for, but I know it's dangerous to criticise comments or submissions on HN, that's supremely frowned upon, so I apologise for sullying the thread with such criticism.
edit: I mean, read the comment thread from top to bottom - isn't that exactly the kind of elitist snorting that the "My fellow geeks, we need a talk" submission was trying to address?
This is an old comment, so I'll not type out a long reply, but note that bcrypt has random salts while your scheme has a fixed salt. With a large database of passwords plus your fixed salt, an attacker can try each calculated hash against each hashed password in your database. With sufficiently long random salts (bcrypt has 2^176 ~= 10^53 bits of salt, if I count correctly), the attacker only gets to try a calculated hash against one hashed password.
And yes, you should tune the number of rounds to get something sensible for your application.
Since you edited out "be useful or go elsewhere," I know that you're thinking your orders to us are a bit across the line, too. They are. Might as well finish it off and edit them all the way out.
Now, on to your URL:
I've tired of people mindlessly chirping the bcrypt approach for storing passwords, particularly that very blog post, when really there is absolutely nothing wrong with hashing. This line particularly irks me, amongst others:
> Salt or no, if you’re using a general-purpose hash function designed for speed you’re well and truly effed.
The author glosses right over keeping a separate salt (shared secret) outside of the database itself, so that you need two separate compromises -- application code and database -- in order to retrieve plaintext passwords. He also claims that "salts won't help you" plain text full stop, without justifying that remark well in the article, and completely avoiding their utility at preventing a rainbow attack.
Instead, the entire article resorts to fear mongering, and I'm tired of people citing it. I will continue using hashing, and watch as the Anonymous groups and so on pick off the low-hanging fruit.
If you mindlessly copy and paste that URL to me without fully and objectively understanding the implications of what you're implementing, and why bcrypt might not be right for you, you really should step back and rethink your decision. In particular, if your app is handling a lot of logins, you're going to become CPU bound extremely quickly. Using the author's benchmark of 0.3 seconds for a simple password hash, how many simultaneous login attempts do you think it's going to take to saturate a core?