[jonny_noog]

So what, I'm meant to reply with something like "Um, my users are people..." and then you say something like "Well people pick shit passwords..." and so on.

Did the SHA eat your babies or something? :P

Seriously though, probably "over the top" was not a good choice of term. In a perfect world, I agree with the unspoken point you're trying to lead me into, which seems to be that all applications should never compromise on their security regardless of convenience or who their users are etc. But surely you must agree that in the real world this isn't always viable. I don't have unlimited time at my disposal.

If my current situation allowed it, I would use bcrypt based solely on the fact that OpenBSD recommend it.

However, my current situation does not allow this. Therefore, I have made a pragmatic decision that will enable me to continue moving towards my goal. I'm not going to apologize to you or anyone else for this.

I appreciate that you are passionate about what I assume is your chosen field of expertise, but perhaps in the future you could try talking to people more so than down to them. You might just find it yields friendlier results.

[tptacek]

No, you've totally missed my point. I wanted to know, do you not have real users? Can arbitrary people not sign up for your application? Does it have a closed user base? Is it an enterprise product? Because, then, maybe password storage isn't an issue for you.

Otherwise, your users aren't simply giving you "shit passwords". They're giving you their bank password. Normal people do not make up 16 different passwords for all their web applications. If you take passwords from normal people on the Internet, and you ever get popular, you will come into possession of a large database of Bank of America credentials.

So yes, maybe you ought to consider being careful with them.

[jonny_noog]

Doesn't using the same password everywhere (particularly if it's also your online banking password) qualify it as a "shit password" as I so eloquently put it? :)

In any case, I accept that there should be some degree of responsibility taken by the developer to try and protect their users information, lest we get the whole Reddit situation.

But as someone once said, you can't make the Internet idiot proof.

[kaens]

Perhaps that doesn't make it a "shit password", but it certainly is a "shit password policy".

Regardless, you can't realistically force your users to not have a "shit password policy". What you can do, however, is make sure that your app is probably not the point of failure for their password.

You can't make the internet idiot-proof, but you can make your apps reasonably malicious-person proof, and it's viewed by some (me) to be close to a moral responsibility of yours to do so - you either already know about, or are probably easily able to learn about "good" security policy, and ways to store users passwords and do validation while minimizing the risk of a malicious person acquiring your users passwords.

That is not to say that writing your own authentication / password storage scheme is something that you just shouldn't ever do - it can certainly be educational and entertaining - but 9 times out of 10 what you write probably shouldn't be used in production.

[jonny_noog]

Hmm, so now we're moving onto 90% of the time you shouldn't use your own authentication / password storage scheme in production? So now it's not just the encryption algorithm, it's the whole login/permissions system that I should rip out? I'm not even going to touch that one, sorry.

This whole conversation is based on the above users belief that unless you are using bcrypt to encrypt the passwords in your database, you are doing a moral disservice to your users. I and at least one other guy have chosen for varying reasons to use salted SHA256.

If anyone can prove to me that salted SHA256 is easily crackable, not by NSA super computers, but by some guy who just might want to steal the database of my little application and crack my users passwords, then I will strongly reconsider my choice. This is not a dick size competition, I'm not a security expert, I'm not challenging anyone to prove me wrong, because I don't think I have the first hand knowledge to know if I'm right or not. But all the material I have found so far tells me that salted SHA256 is still viable encryption for my purposes.

If it's not, then I am genuinely interested to see the conclusive proof.

[kaens]

I wasn't necessarily saying you should rip anything out of your system. I haven't examined it, nor am I an expert on security (encryption, particularly is a rather complicated area filled with implementations with very subtle flaws, possibly undiscovered).

I wasn't trying to come of as critical of you, although I can see how my post could be read that way - I was just making the point that homegrown stuff in this area has a notorious reputation for being unreliable.

I would argue that if using bcrypt makes your passwords harder to crack than using SHA256, there isn't much of a reason to keep using SHA256 - salted or not - regardless of how hard SHA256 is to crack.

And yes, 90% of the time, authentication / password storage schemes exist for whatever framework or platform that you're using that have been thoroughly tested by people who probably know their stuff better than you or I - and, from a security standpoint, it's probably better to use their scheme as opposed to writing one yourself.

[jonny_noog]

I can see where you're coming from. And trust me, I'm keenly aware that there are many people who have a better understanding of this and other issues than I do. This is the main reason why I'm using a framework to begin with.

However, as far as I can tell, none of the ready made authentication/password storage schemes for Rails use bcrypt in a cross-platform way, if they did I'd switch over. Where does that leave us? You can take that as a rhetorical question if you like.