Ask Slashdot: Is SHA-512 the Way To Go? 223
crutchy writes "When I was setting up my secure website I got really paranoid about SSL encryption, so I created a certificate using OpenSSL for SHA-512 encryption. I don't know much about SHA (except bits that I can remember from Wikipedia), but I figure that if you're going to go to the trouble (or expense) of setting up SSL, you may as well go for the best you can get, right? Also, what would be the minimum level of encryption required for, say, online banking? I've read about how SHA-1 was 'broken', but from what I can tell it still takes many hours. What is the practical risk to the real internet from this capability? Would a sort of rolling key be a possible next step, where each SSL-encrypted stream has its own private/public key pair generated on the fly, and things like passwords and bank account numbers were broken up and sent in multiple streams with different private/public key pairs? This would of course require more server grunt to generate these keys (or we could take a leaf from Google's book and just have separate server clusters designed solely for that job), but then if computing performance was a limiting factor, the threat to security of these hashes wouldn't be a problem in the first place."
(Continued below.)
"I guess with all security infrastructure, trust becomes a more important factor than technical abilities. Can I trust that my SSL provider hasn't been hacked (or at least snooped)? How do I know some disgruntled IT admin hasn't sold the private key of his company's root CA to the same organization that developed the conficker virus? It would certainly make for a more profitable payload. I've read some of Bruce Schneier's work (I'm subscribed to Cryptogram) and he tends to highlight the FUD that surrounds internet security, and I agree that there is a lot of FUD, but complete ignorance and blase attitude toward security can also be taken advantage of. Where is the middle ground?"
Re:Here we go (Score:4, Interesting)
I'd even say IF this isn't just tinker-toying with security and trying to find something cool and nice to put together, go with a pro: Hire someone or buy a solution that suits your needs.
The reason is simple: Security is the one thing you can't really test sensibly yourself whether it's doing its job. For a server, you can easily check whether it's working; Can you connect, can you see what you're supposed to see, does everything run as it should, etc. Security? Until someone tries to break it, you'll never know for sure whether it was set up correctly.
I've seen it time and again in audits, companies (even rather well known ones) that considered themselves "secure" because they hashed out some kind of security system, only to see it crumble under the first few kicks I gave it. Why didn't anyone notice, why wasn't it discovered earlier? Because they didn't know what they were doing, and because they were lucky enough that no "bad" people tried it before they called us.
Allow me to add that security is not only a matter of the algorithm used, what also matters is how it is implemented and how the system handles it. A metaphor I love to use is this: The best, most stable security steel door is useless if your walls are made out of paper. For reference, play Monkey Island.
Don't rely on a hash, and not on a single defense (Score:5, Interesting)
First of all, congratulations that you try to take security serious. Even though what I can tell from your questions is that any answer we could give you here would leave you with even more questions and very little enlightenment. A few very good books have already been recommended, and I'd recommend the same that was already said: Go read. Don't implement a security scheme, don't even plan it. Go read the books, teach yourself what's necessary to actually understand what you're doing and then go and plan your security.
On the danger of sounding patronizing, but that's simply as it is. It doesn't matter if you use MD5 or SHA-512 before you understand how to use them in a secure way. I gave the parallel of the steel door with paper walls above, so I won't repeat it, but security is always the security of the weakest part. If someone can bypass your secure entrance, the whole security is voided. I've seen too many rely on a "strong" hash only to see that the algo used was weak and allowed other ways of attacking. I can easily recommend anything Bruce Schneier wrote, he sure is one of the security gurus of our times and his books aren't as dry as many others on the subject. I'd start with the already mentioned "Applied Cryptography".
While we're at it, something I would also highly recommend is to implement a "fail well" [wikipedia.org] strategy. Another thing I've seen many, many times ignored, and it's maybe the easiest way to improve security in a system, especially if the person responsible for it is not a security guru himself. The general idea is that, if (ok, when) security gets broken, the system should not instantly be fully accessible to the perpetrator. Try to compartmentize and contain the damage. Many times it is quite easy to do but ignored for simplicity's sake, like using the same database user (with admin privileges, of course) for different databases or using the same credentials for different systems. It's, IMO, the first step to more security and it can be easily implemented without a lot of knowledge of security because most of it is in the administrative field, not the technical one.
Re:Here we go (Score:5, Interesting)
If you're securing something like THAT, it's very sensible to use algorithms that permit decoys using one key and hiding the real data under an alternative key. Truecrypt does this, for example.
Re:SHA-256 is enough (Score:5, Interesting)
I use SSHA-256 (salted/seeded SHA-256). I haven't even looked at going to 512.
One thing I do, though, is store a prefix to all my hashes denoting the algorithm used. That way if anything better comes along down the road I can start using the better algorithm for new accounts and password changes and will hash user input during login based upon that prefix. That way legacy passwords do not break.
I do not know if I weaken my security by prefixing the hash with something like "{SSHA256}", but I am not one to rely on obscurity for security.
Re:THE SOLE ANSWER (Score:5, Interesting)
Bruce Scheneir once said "A colleague once told me that the world was full of bad security systems designed by people who read Applied Cryptography". See more on that in the preface to Secrets and Lies [schneier.com]
A single book, no matter how good, doesn't make one an expert. Now if you're interested in crypto, by all means get it. I have it and I think it's a good one. But it makes oh so tempting to start coding something without really understanding what are you doing and why. Be careful with that.
Now, despite the excellent intro, I think Secrets and Lies is of more value to normal people than geeks. I think it's a fine book, but to anybody who already is interested in security and crypto topics a very large part of it is going to come off as blindingly obvious. It's a good book to have to lend to non-technical people though.
Re:Calm down and read up (Score:4, Interesting)
Crypt::SaltedHash is significantly less secure than PBKDF2. It doesn't iterate the hash, which is a very good idea for password hashes, as it significantly increases the cracking time (very important for not-so-good passwords). Hashes are meant to be fast, so deliberately slowing down the algorithm helps a lot. Going from 10000000 cracking attempts per second to 10 cracking attempts per second is going to stop a lot of attacks, and all it takes is using a properly designed algorithm instead of just sticking the password and a salt into a hash (which is what SaltedHash does).