Slashdot Mirror
Ask Slashdot: Is SHA-512 the Way To Go?
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?"
This will probably get marked flamebait, but I feel it needs to be said.
If you are working on something where you believe or you've been told this level of security is necessary, yet are at a "what's even out there" stage, you really need to bring someone with experience onto the team.
If this is just for a personal blog or something and you are just having fun with security, then by all means go for it. People are gonna tell you that you are insane, that plain ol` "out of the box on most distros" SSL is gonna be fine, but if you enjoy playing with this stuff then no harm throwing practicality (and your time) out the window and having fun.
I'll also note that the problem with implementing anything beyond SSL is the age old legacy problem. You can probably come up with a very secure scheme, but if no one's browser can handle it, you'll be playing with yourself!
Not 42.
Read this book:
http://www.schneier.com/book-applied.html
Problem solved. You understand the basics of crypto, and can now make decisions!
Ask Sony what they used, then find something 10x stronger.
SHA-2 (of which SHA-512 is a part) isn't encryption, it's a hash function.
If you're going to work on cryptographic security or have even a passing interest in encryption, Schneier's Applied Cryptography is a great place to start.
Trolling is a art,
SHA, which stands for Simply Hard Enough, has always been considered the successor to MD5.
As the numbers suggest, SHA1 5). SHA512 is formidable indeed, and no respectable website will go with anything less than SHA500.
However, there is always a balance between security and convenience, and it's important that you discover this for yourself and your users. If, for example, you find yourself with more than 500 users, you may want to bump up to SHA1024 to make sure you have enough room. Better yet, look into elliptic-curve algorithms that can be stretched to fit.
Also consider using Python instead of PHP.
SHA-512 encryption
SHA-512 is a hash function, not a cipher.
if you're going to go to the trouble (or expense) of setting up SSL
What trouble and expense? TLS (SSL is obsolete) is only expensive if you need to get your certificates signed by a commercial CA i.e. if you are interacting with random people who are not affiliated with you or your organization. If you are only deploying TLS for internal purposes, just maintain your own internal CA and deploy your internal signing key to all of your organization's systems.
Also, what would be the minimum level of encryption required for, say, online banking?
AES-128 is perfectly reasonable here; it has a sufficient security margin for online banking and is nowhere near the weakest link in the security chain. If you happen to have extremely sensitive information and you need >30 years security, a more conservative cipher like MARS or Twofish might be appropriate (given the attacks on the AES-256 key schedule; in any case, 256 bit ciphers are recommended for >30 year security last I checked). Really though, any of the AES finalists are fine.
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?
CAs should not be trusted; the CA system is based on a typically bad assumption, which is that there are enough users who are aware of what it means for a CA to be untrustworthy to force the CAs to exercise appropriate security policies (or lose their business). Since only a tiny minority of Internet users even know what a CA is, and only a tiny minority of those people know how often CAs issue signatures for fraudulent certificates, the assumption does not hold. CAs are not trustworthy and should not be trusted.
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
You should take more time to read about cryptography. Confusing a hash function with a cipher is not a good indication that you have the minimum level of knowledge needed to understand what Schneier is saying.
Palm trees and 8
You might want to have a look at http://www.keylength.com/ (overview of all 'official' recommendations regarding protocols and minimal keylengths).
If you work for banks: take into account the Payment Card Industry standard (https://www.pcisecuritystandards.org/ - strictly speeking only valid for credit card handling systems) and look at national compliancy requirements ...
https://pangseh.com
Quite the opposite. The chances of someone coming up with something nontrivial that is more secure than SSL on their own are practically zero. Inventing your own cryptosystem is a sure-fire way to end up with something insecure. Don't do it.
To the original asker:
Calling SHA-512 (a cryptographically secure hash) "encryption" is your first clue that you need to either 1) calm down, learn about moderm crypto, about what all of those funky acronyms and bit sizes mean in practice, or 2) hire someone who does. There is no "shortcut". If you plan to use SSL, at the very least you need to know the difference between a cipher and a hash, and some vital information about the different choices that you can make.
And please, please, please don't invent workarounds, hacks, wrappers, tricks, or anything else on top of SSL or any other cryptosystem, like that multiple stream thing (and don't even think about implementing your own from scratch). These systems were (hopefully) designed by experts in cryptography who know the implications of their design decisions, which can be devastating for security if done wrong. They don't need wrappers or workarounds to stay secure, and they certainly don't need to be reinvented. "Shotgun cryptography" (throw every buzzword and algorithm in there, because more bits and more layers is more secure!!1) is exactly what made the PS3 a cryptographic laughingstock and gave everyone Sony's private keys. Don't make that kind of mistake. SSL works just fine as is, and you can almost certainly make it do whatever you actually need without having to hack around it.
I could write a few lines attempting to answer your questions about SHA-512, the SHA-1 attacks, etc., but I won't, because the questions are wrong to begin with. Start by understanding what you're asking first, then you'll be able to ask relevant questions. You don't need blind instructions that are ultimately going to lead you somewhere without really knowing where you're going; what you need to do is get a map and figure out where you are and where you want to go first.
"""
Replace "hours" with "centuries". Or maybe more. Nobody has ever created a SHA-1 collision.
"""
There is however a theoretical attack (2^{52}) discovered in 2009 (better than prior breaks). It has been recommended to go for SHA-256 or SHA-512 until the next hashing algorithm standard comes out. In fact, this recommendation is years old.
The SHA family is coming to an end; it's just a matter of time. And I would suspect that we'll see that day sooner rather than later (read: decades).
I like Bruce, if that's enough. :)
And if you take your security with a grain of salt they lose a lot of their byte. (ok, ok, I'll stop with the puns)
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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" 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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
Rainbow tables are basically premeditated brute forcing. They're only useful to attackers when the password hashing in use is weak. Which is quite still common, unfortunately.
For example, every developer knows (or damn well should) that it's a remarkably bad idea to store user passwords as plaintext in a database. So when it comes time to write the code, many of them just pick an arbitrary hashing function that isn't widely known to be broken and move on. After they're attacked and the user database stolen, all the attackers need to do is run the database against any of the common rainbow tables floating around and they have the passwords for a good percentage of the database.
Some people will say, "well duh, that's why you add a salt before you hash!" But where do you propose to store the salt? That's right, in the database. The one that the attackers may eventually have access to. It might cost them some time, and possibly some money, but it wouldn't be at all impossible to rent some time on EC2 or a botnet to effectively create their own specialized rainbow table for the job.
It is still not common knowledge that you need to use a more secure password hashing function. This is called key stretching. Key stretching makes it deliberately expensive to brute-force every password combination and, to an extent, dictionary attacks. Plain old hashing functions are designed to be very quick and efficient. You can generate thousands (millions?) of hashes per second on modern hardware. A good password hashing function which employs key stretching is deliberately designed to be many orders of magnitude slower so as to make brute-forcing and rainbow tables computationally infeasible. The idea is, if each guess takes 2-3 seconds to compute (as opposed to 2-3 milliseconds), you will be waiting a very long time before you have anything close to a usable rainbow table.
This doesn't mean users are off the hook when it comes to using secure passwords. Even with key stretching, any dictionary-based password can be found with some patience. But a secure hash of any reasonably "random" password can be safe for a very long time even if^H^Hwhen the password database is compromised.
The SHA family is coming to an end; it's just a matter of time.
An end, but also a beginning; the final selection of the hash algorithm that will become SHA-3 is scheduled for 2012.
The current candidates are all faster than SHA-1 on platforms without hardware acceleration, even with the added security. Unless a weakness is discovered after the standardization, SHA-3 should eventually replace SHA-1 in all security critical applications.
In a fair world, refrigerators would make electricity.
Salting has been around since the 70s and it makes rainbow tables completely useless. If I add salt, I'm now storing H(salt & pass), where & is binary concatenation. Now if my salt is, say, 16 bits the rainbow table be 65536 as large and take 65536 times as long to generate. 32 bits of salt makes *each* password require 4 billion entries.
So the only reason anyone is being cracked by using rainbow tables is that they are making well known mistakes trying to solve problems that have been solved thirty years ago.
You must store a separate, completely random salt for each stored hash. There should be a SALT column in your database along with USERNAME and HASHED_PASSWORD. The salt is not supposed to be a secret! The salt is to force the attacker to attack each hash individually and to make rainbow tables infeasible. Salting does not actually make any individual password harder to break, it makes it harder to attack *groups* of passwords.
Do not store one salt for the whole system. Do not use the salt as a key to a cipher on the hash, e.g. C(key=salt, H(password)) does not work, nor does H(password) XOR salt. Do verify that the salts really are random. Do use a reliable RNG, like /dev/urandom or Java's crypto PRNG.
The next item is to use a hash function that is designed for password hashing. MD5, the SHA family, etc., are fast hashes, designed to digest huge amounts of data quickly and prevent collisions, accidental or deliberate. These have important security applications, but they are not appropriate for hashing passwords.
If you're hashing a password, use a slow hash, one that can be "stretched" to take seconds of CPU time. If it takes a second of CPU time to hash a password, your attacker is going to need 6622 years of CPU time to break an 8 character A-Z password, whereas you'll need one second to approve a valid user. Even assuming it's some years down the road and they have specialized hardware, you can have passwords that are a reasonable length and still infeasible to break.
Don't try to roll your own slow hash by using many rounds of a fast hash, there are slow hashes that have been designed and reviewed by the security community. bcrypt is one I often hear about, but search around, there are others.
And lastly, when it comes time to upgrading your login procedures whether hardware or software, you aren't going to know anyone's password. If you change, say, the hash or the stretching parameter or the salt length, you'll need users to go through a change password screen! That means you have to design your application to handle users having different algorithms with different parameters. All this should really require is adding HASH_FUNC and STRETCH_FACTOR columns.
It sounds like you have an oversimplified idea of "security". Security is not a scalar property that increases with the number of bits in a hash or key. Security depends on your threats, and it's possible to be reasonably secure without the addition of any cryptography at all (although this will be the exception rather than the rule). Let's discuss security threats for a moment.
One threat is that of the eavesdropper. This is the classic threat from online shopping: "OMG, some hacker will see my CC number when I submit it to the shop." This threat can be defeated with encryption -- sort of. You don't need any kind of "certificate" to effect this level of security: you just need a key-sharing technique which defeats a passive eavesdropper. SSL/TLS has this, and it's independent of the number of bits in any hash, since that's a different part of the security puzzle.
Now the bad news: your CC number will still be compromised, despite your super-strong encryption. If you're using a malware-prone OS, then any malware on your system makes an end-run around the encryption. If you're using a public terminal, you need to be sure that it doesn't have keyloggers installed on it, either hardware or software. And even if your client-end computer isn't compromised, your CC number will be stored in a PCI-compliant database, where "PCI-compliant" means "this kind of thing gets compromised several times a week, leaking X thousand CC numbers in one go" for large values of X.
Encryption of the channel, in this case, provides security against the least convenient and least likely attack. You should probably encrypt the channel anyhow, but you simply can not achieve security, because most of the real threats lie outside your control.
Another threat is the impostor. This is where someone gets lured into going to BadGuy website which is dressed up as GoodGuy website. This is where public key certificates are supposed to help, and that's where you need to worry about how many bits there are in the hash. But if you're worried about the number of bits in the hash, or the kind of hash algorithm, then you're probably fussing over the smallest of problems. Certificates have a very limited lifespan, and so long as your current one isn't at the bottom of the pile, strength-wise, it's probably satisfactory for now.
The real problems that you face in this case are usually beyond your control. You can't create a self-signed certificate in general, because every browser on earth will throw up a warning (that 99% of users won't understand anyway) saying that the certificate can not be verified. You don't want that: you want the browser to do the "I'm secure now" thing, whatever that happens to be, visually. So you'll need to pay up for a certificate. Unfortunately, your clients must then be smart enough to pick the difference between your website with its "I'm secure now" indicator, and an exact copy of that website which lacks this indicator at a different URL, or one that has an "I'm secure now" indicator which doesn't match your identity. How smart are your clients?
If you're a really important target (e.g. Gmail), you have much bigger worries. You ask, "Can I trust that my SSL provider hasn't been hacked (or at least snooped)?", but the problem is much worse than this: you need to trust that every issuer of certificates on Earth hasn't been compromised, which you can't, because some of them have. When any certificate issuer is compromised, it's possible that a fake certificate has been generated for your identity, and someone else can set up a server which validates itself as "secure" for your domain name. There are browser add-ons in some cases that will raise a red flag when a "valid but previously unseen" certificate is shown, but then you're asking for even greater security expertise on the part of your end users to diagnose the situation.
So, in summary, step away from the key-generation software, and go back to square one. Think about your threat model, and whether any of your crypto-
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
As most folks here have pointed out already, you are in over your head. First, you need to understand that the strength of the hash used to setup an SSL session isn't necessarily an indicator of the strength of the SSL session encryption. Your concern about server power isn't warranted as the strength of the cert used to start up the SSL session is negligible. My advice is to stick to standard methods and don't try to get inventive. You have much bigger things to worry about that the strength of your SSL cert. Like making sure everything else is secure and that you're not subject to things like SQL injection or stolen cookies that result from shoddy programming.
so I created a certificate using OpenSSL for SHA-512 encryption
Great, so now your clients have no real way of verifying the authenticity of your web site. If you intend to deal with the public, get a certificate from a reputable provider that typical browsers already trust. Self-signing is a sure sign of an amateur and usually people don't trust a website when the browser keeps nagging them that the certificate is not trusted.
"Can I trust that my SSL provider hasn't been hacked (or at least snooped)?"
Another clue that you need help. There is no such thing as an SSL provider. There are providers that sign certificates intended for specific (or general) purposes. What you do with them is your problem.
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?
You don't. But keep in mind the risk of a compromised certificate is primarily the threat of someone else pretending to be you, such as a fake site or a man in the middle attack. If you're issuing certs to clients for authentication, the risk is that a compromised cert means someone else can pretend to be your client.
Hmmm... well, most hash algorithms are made to be fast. This is unfortunately the wrong thing to do for passwords. The SHA family of algorithms process many megabytes of data per second -- they have to, they are general purpose. The hash algorithm that I use for passwords generates 4 per second on a fast server. The CPU strain only occurs during authentication, and those are time delayed anyhow (to avoid timing/side channel attacks). For a brute force attack this means cracking even one password is significantly more difficult.
Instead of the SHA family use a function that is computationally intensive AND RAM intensive (like bcrypt). Any hash algo that requires a significant amount of memory to operate is much less feasible to run in parallel. The SHA family of hashes require little memory even when key stretching is used. Ergo, the number of hashes that can be computed at once relys primarily on your processing power. Even a 4K pool significantly increases the memory requirements of a hash -- effectively tying the hash to RAM size as well as CPU/GPU power. System memory to GPU is a slow transfer, GPUs typically have less RAM than main system memory -- use this to your advantage, there is really no reason not to.
Also note: do not use a single salt for every hash in the DB -- use a different salt for each PW. This completely defeats "Imma build a rainbow table" based attacks.
IMHO SSL is often not the problem. Most websites/webapps are hacked through badly configured and unpatched servers or through programming errors in the site itself. If you're concerned about security, make sure that your website/webapplication/cms is secure. OWASP is a good source for hints and tips. They even have a top-10 for this stuff. So, if SHA-512 is you're only problem, you're doing just fine.
the use of knowledge is highly overrated
I'm sorry, but this borders on nonsensical... Assume each user has a distinct, hopefully large (at least 32-bit and preferably 64-bit) salt, generated by a cryptographically secure PRNG and the SHA-1 algorithm for hashing. What does this mean? If Eve somehow gets a dump of the salted-hashed passwords from Alice's database, she would need to generate a unique rainbow table for each user. Sure, Eve could just target one particular user from the database -- say Bob -- explicitly and get together enough computing power to attempt to mount a brute-force attack on the salted-hash, but that's an awful lot of work to compromise one account.
So much work, in fact, that will almost certainly make an attacker choose a different attack vector. It's just an impractical attack for all but the most well-funded adversaries -- adversaries who work for three-letter government agencies that employ more mathematicians and programmers than you can count, and who run massive data centers that require their own, dedicated power plants -- and who are targeting a particular very-high-value target, we're talking about the sort of attackers who work for .
Password stretching, as you mention, is a great idea, and more people should use it. But a simple salted hash, provided the salt is large and the hash is cryptographically secure, is almost certainly good enough for the vast majority of applications.
Ha, you want security and trust? Remember Ken Thompson's C Compiler Backdoor
Make sure you built your PC out of sillicon yourself! Otherwise, you have to rely on someone else's code:
ACM Classics: Reflections on trusting trust
http://cm.bell-labs.com/who/ken/trust.html
If you're hashing a password, use a slow hash, one that can be "stretched" to take seconds of CPU time. If it takes a second of CPU time to hash a password, your attacker is going to need 6622 years of CPU time to break an 8 character A-Z password, whereas you'll need one second to approve a valid user.
Don't try to roll your own slow hash by using many rounds of a fast hash, there are slow hashes that have been designed and reviewed by the security community. bcrypt is one I often hear about, but search around, there are others.
Agree entirely with you. However, you could do even better than bcrypt (which is very good already). The reason is that bcrypt (and the like) only depend on a lot of CPU time, but do not demand a lot of memory. CPU time is much easier to come by than memory, and easier to parallelise. One algorithm that uses both a lot of CPU time and a lot of memory is scrypt. The author estimates that (with the same constraints on the time taken to calculate the derived key from the password) scrypt is typically at least 30 times more expensive to an attacker than bcrypt.
More information on scrypt here: http://www.tarsnap.com/scrypt.html