|
|
|
|
|
by jonny_noog
6438 days ago
|
|
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. |
|
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.