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?"
Here we go (Score:5, Insightful)
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!
Re: (Score:3, Informative)
As the prior poster said, you don't know enough of what you're doing to even begin. Go pick up a copy of Applied Cryptography, spend 3-4 weeks reading it, and then at least you'll have perspective and can begin deeper research. Actually, Applied Cryptography should tell you everything you need to know for nearly any application.
Re: (Score:3)
Applied Cryptography is an awful book if you really want to build something. It's basically a giant algorithm survey. And while some of the more unusual algorithms are pretty useful in some limited contexts, it gives you very little guidance on which algorithms to use when and why.
I would instead suggest Practical Cryptography. It has the information the OP would need to answer the exact questions he's asking. It gives you really good information about which algorithms to use when and why, and how to design
Re: (Score:3)
I would instead suggest Practical Cryptography. It has the information the OP would need to answer the exact questions he's asking. It gives you really good information about which algorithms to use when and why, and how to design secure systems by combining the various kinds of algorithms and offers guidance on how to pick them.
They renamed it "Cryptography Engineering" for the second edition, just in case someone goes round looking for it can only find the first edition. I don't actually know how different it is, mind you.
Re:Here we go (Score:4, Funny)
Pfft, noobs! The best book is Impractical Cryptography by #5fgj@!53!@. You can't even read it without breaking the cypher (key sold separately).
Re: (Score:2)
Actually Applied Cryptography should give you the false feeling of security which will undoubtedly bite you in the ass when your system is tested in a real-world security environment.
It's not that the information is bad. It's not, the book is excellent. It's just that so many people are completely incapable of judging their own competence and will make stupid newbie mistakes even when they are guided by the most excellent of resources and advice.
Go ahead and read Applied Cryptography. Go ahead and implement
Re: (Score:2)
That's why security guys always seem paranoid. Security is a moving target and has to be frequently audited. The solution that was good enough today may be useless tomorrow and what was great today may simply be good enough tomorrow
The other thing is trying to balance good security with the appropriate level of usability for the scenario in question. That is as much an art as it is a science.
Security is like a fortress, in that there is always a weakness you haven't thought of and unmanned there is an even
Re: (Score:2)
Think he's be best starting with Cryptography for Dummies: http://www.amazon.com/Cryptography-Dummies-Chey-Cobb/dp/0764541889 [amazon.com]
Then on to the other suggested books...
Calm down and read up (Score:5, Insightful)
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.
Re: (Score:3)
Notable exception: salt your inputs to hashing algorithms when recording passwords and other data that can be attacked with rainbow tables.
Re:Calm down and read up (Score:5, Informative)
Inventing your own method of hashing passwords (based on a standard hashing algorithm) counts as making up your own cryptosystem (sadly, the vast majority of web programmers seem to fall into this trap). You should be using a standard password hashing mechanism, such as PBKDF2 [wikipedia.org] (RFC2898). Although the name implies symmetric key derivation (Password-Based Key Derivation Function 2), it works just as well for hashing a password before storing it in a database, and it's much better than 99% of the schemes in use out there.
Re: (Score:2, Informative)
If you're using anything other than PBKDF2, bcrypt [codahale.com] or scrypt [tarsnap.com] to store your user's passwords, you have already lost.
Re: (Score:2)
Nonsense. A simple, properly implemented salted hash is perfectly adequate for the vast majority of sites, provided you use large (at least 32 bit and preferably 64 bit) random salts, and a cryptographically secure hash algorithm (although I would avoid MD5).
00894983a50dc526-0e71bd5a380617a402bd24c6be3e7a7f2dd06109
This is salted password, hashed with SHA1. The salt is the part of the data before the dash. Please show me how I lost?
Re:Calm down and read up (Score:4, Insightful)
Cryptography doesn't work that way. The onus is on you to demonstrate that your scheme is secure. Anyone who doesn't have the expertise to do that (which is almost everyone) has to use a scheme that was developed by someone else and vetted by others as well.
It is trivial to make a scheme that you yourself cannot break. It is not that hard to make an insecure scheme whose insecurity cannot be easily demonstrated.
Re: (Score:2)
Actually, a simple salted hash *IS* a validated algorithm. But don't do it because some guy on Slashdot said it was okay. ;)
Re: (Score:2)
Re: (Score:3)
00894983a50dc526-0e71bd5a380617a402bd24c6be3e7a7f2dd06109
Weird. That's the passcode to my briefcase.
Re: (Score:2)
He didn't say he was inventing his own method at all. Your lack of education is showing; there are a plethora of cryptographically sound hashing libraries available. Please research the topic more thoroughly and review available resources such as Crypt::SaltedHash [cpan.org] before attempting to dissuade others from following what was not only sound advice, but critical advice for folks who deal with legacy systems and don't even know about salting.
If you feel I'm somehow misguided on this topic, I'd encourage you to
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).
Re: (Score:2)
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).
Store the number of iterations alongside the salt and hash. This way as computers get faster you can rehash your password database once a year by increasing the number of iterations.
Re: (Score:2)
Re: (Score:2)
The only comment I would like to add is that there may be some clever people out there who might be able to devise a simple encryption algorithm that may be stronger than SSL
Either impossible or very easy depending on how you look at it, since SSL is not encryption algorithm... SSL is cryptographic protocol which generally uses two encryption algorithms, an asymmetric one for authentication etc, and symmetric one for session data encryption. It also bunch of other cryptgraphic algorithms, at least a hashing algorithm and a key exchange algorithm.
Re:Here we go (Score:4, Insightful)
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: (Score:2)
This is a good reason for session keys and Diffie-Hellman style key exchange. Using those there is no way to decrypt a captured datastream afterwards (assuming each end lives up to their end of the bargain and discards key data at connection end).
this doesn't mean you won't still get a wrench to the face, but SSL has done kit's job by then ;)
Re: (Score:2)
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.
Re: (Score:2)
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.
This is very true. Reminds me of a story someone told me once. He was going over to a secure datacenter his company was using to see for himself how they handled things. He got there and had to admit they seemed to actually know what they were doing. Until he felt a draft... One of the employees inside the center had decided it was a bit too hot in there and propped open a door to let air in. All it took was one person's bad decision to nullify everything else they had done. Remember people, weakest link...
Re: (Score:2)
Seriously, the cannibals in MI and their increasingly secure door is a perfect example for the way some companies treat security. Whenever the need arises that "more security" is required (hardly ever, sadly, security is mostly dictated by the law, not by internal pressure), the steel door gets bolstered, often to the point where normal operation is no longer feasible, the nobody ponders the fact that an invader doesn't care whether the "house" remains in one piece, he'll simply come through the wall. Allow
Re: (Score:2)
you'll be playing with yourself!
Whats wrong with that?
Re: (Score:2)
SHA-1 can be broken for document hashing. Use SHA-512 there. Also for encryption.
For password hashing, SHA-1 is sufficient, although there is no harm in using SHA-512. The reason SHA-1 is not broken here is that the hash (or seed) is not known to the attacker so he can not forge a cleartext with the same hash. This is why it is different from document hashing / encryption.
There is no reason to use MD5 anymore, The SHA-ciphers are superior.
Re: (Score:3)
There is no reason to use MD5 anymore, The SHA-ciphers are superior.
For web site security, you're right.
It's still useful as a checksum algorithm. I use it on my photos to determine if software has messed with the metadata. Clearly we're not talking about a security application here.
Re: (Score:2)
To be precise, there is no reason to use MD5 other than when you have to interoperate with something that uses MD5 and can't easily be changed or when you're already using it and it's good enough for your application. You're not using MD5 to verify your photos because it was a considered choice, you're using it because you have no particular reason to change it.
Re: (Score:3)
It's still useful as a checksum algorithm. I use it on my photos to determine if software has messed with the metadata. Clearly we're not talking about a security application here.
You may as well use CRC32, though, which is just as useful for that application and much, much cheaper to compute.
Re: (Score:3)
Re: (Score:2)
you really need to bring someone with experience onto the team.
That's essentially what he's doing.
THE SOLE ANSWER (Score:2, Informative)
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!
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: (Score:2)
Ask Sony (Score:2, Funny)
Ask Sony what they used, then find something 10x stronger.
Re: (Score:3)
Bad advice. 10 x 0 = 0
Even ROT-13 would be better than what Sony was using.
Re:Ask Sony (Score:5, Insightful)
Sony was using pretty much every modern cryptographic algorithm in every possible way.
All at once.
And that is why they failed miserably.
People who think cryptosystems are made of buzzwords like AES and SHA and ECDSA and numbers of bits are doomed to create insecure pieces of crap. To make a secure cryptosystem you only need a couple good algorithms and, most importantly, one or more professional cryptographers to design the overall system for you. Or do the sane thing, and use an existing cryptosystem correctly instead of even thinking about rolling your own.
Re: (Score:3, Funny)
Whatever you do, avoid ROT-13 ten times :)
SHA isn't encryption. (Score:5, Informative)
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.
Re:SHA isn't encryption. (Score:5, Informative)
Mod parent up.
There are four parts to SSL: Ciphers, Hashes, Randomness, and Public Key Crypto.
Public Key and Hashes are used by the SSL endpoints to validate the identity of the other end. Both ends must agree on a mutual Certificate Authority and the web of trust that extend from it.
Randomness is used to create a session key, shared via Public Key to seed the Cipher used to encrypt the session.
Weaknesses in hashes makes it easier to spoof a trusted site. Weaknesses in Randomness makes it easier to guess the Cipher key (this is the vector I've seen exploited the most). Weaknesses in Public Key makes everything vulnerable - which is why people are worried about Quantum Crypto.
Ciphers include: AES, Camellia, DES, RC4, RC5, Triple DES. Hash Functions include: MD5, MD2, SHA-1, SHA-2. Public Key includes: RSA, DSA, Diffie-Hellman key exchange.
Re: (Score:3, Informative)
Mod parent up.
There are four parts to SSL: Ciphers, Hashes, Randomness, and Public Key Crypto.
Public Key and Hashes are used by the SSL endpoints to validate the identity of the other end. Both ends must agree on a mutual Certificate Authority and the web of trust that extend from it.
Randomness is used to create a session key, shared via Public Key to seed the Cipher used to encrypt the session.
Weaknesses in hashes makes it easier to spoof a trusted site. Weaknesses in Randomness makes it easier to guess the Cipher key (this is the vector I've seen exploited the most). Weaknesses in Public Key makes everything vulnerable - which is why people are worried about Quantum Crypto.
Ciphers include: AES, Camellia, DES, RC4, RC5, Triple DES. Hash Functions include: MD5, MD2, SHA-1, SHA-2. Public Key includes: RSA, DSA, Diffie-Hellman key exchange.
Two things:
- Your note about the CA is not quite correct. The term Web of Trust (as I know it) refers to a PGP-like infrastructure, as opposed to the hierarchical model used by X.509 (which implies CAs). The difference is that trust in a CA always means trust in any key singed by it (and thus also the CAs below it in the hierarchy).
For those interested, you can more on this in these lecture notes [win.tue.nl] from my crypto class.
- I know quantum computers can do fast factorisation (ie. break the RSA assumption), but ca
Re: (Score:2)
> If you're going to work on cryptographic security or have even a passing interest in encryption, please don't
fix it for ya.
Yeah, OpenSLL is all fine and good for security (Score:2, Funny)
SHA-1 is fine, but go for SHA-512 (Score:2)
I don't know much about SHA, but I figure that if you're going to go to the trouble of setting up SSL, you may as well go for the best you can get, right?
If that's the way you feel, then yes, go for SHA-512. I think it is the heaviest NSA blessed hashing algorithm.
I've read about how SHA-1 was 'broken', but from what I can tell it still takes many hours.
Replace "hours" with "centuries". Or maybe more. Nobody has ever created a SHA-1 collision.
What is the practical risk to the real internet from this capability?
None for the near future. And CA certs expire after a year.
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?
That would be ridiculous. There are valid concerns about SSL, but only regarding trusting CAs. The problem isn't the encryption itself, but the fact that you require a trusted avenue to exchange keys, and the CAs can't necessarily be trusted. The tech
Re:SHA-1 is fine, but go for SHA-512 (Score:4, Insightful)
"""
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).
Re: (Score:2)
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. [nist.gov]
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.
Re: (Score:2)
There is however a theoretical attack (2^{52}) discovered in 2009 (better than prior breaks).
The authors of that attack withdrew their paper due to a miscalculation. Until they release details, 2^57 is the best published attack. And besides, it is irrelevant to the original poster: the flaw these attacks exploit allows creation of a pair of documents that hash to the same value, but *not* general creation of a document with a specific hash value, which is the only way you could attack an SSL server based on a flaw in its certificate hashing algorithm.
Re: (Score:2)
The multiple streams idea seems risky to me. If you start splitting things up you might be opening yourself it unknown side attacks, timing attacks, and other leaks. As others have said the problems with SSL/TLS are not the encryption but the chain of trust. The best security you are going to get is to use it as designed.
If you are really worried about Authentication, then distribute a self signed certificate out of band. That way there are no chain of trust issues. The other thing you can do is used a
You're right to be concerned. (Score:5, Funny)
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.
Re: (Score:2)
Simply Hard Anough?
Re: (Score:2)
Wait, what? What the hell? That is just completely wrong. You're completely out of touch with the world. You're, in fact, crazy.
Everyone, EVERYONE! knows that hand crafted assembly is the only way to create a web page.
Re: (Score:2)
Butterflies? How quaint.
I just tweaked the universal constant at the start of creation so this comment would spontaneously appear by itself.
Additional info (Score:2)
Don't worry (Score:2)
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
That's precisely how it works already, except that it's not just a public/private pair. Public key encryption is fairly slow, so instead of using it for the entire connection, the parties generate symmetric keys for a block cypher to handle the stream itself, and exchange them during handshake, those keys themselves encrypted by their (also generated) private keys.
SHA-512 is not "encryption" at all, it's a cryptographic hash function. As such, it has no bearing on the security of your data (i.e. SHA512 cert
A few things (Score:5, Insightful)
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.
Re: (Score:2)
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.
Having your own CA raises the distribution problem, which is different or at least flaky for virtually every browser / OS combination, and you're still running on what may as well be a compromised system so TLS is irrelevant since the attacker can just root the system and grab keypresses.
The best solution short of buying laptops and putting epoxy in the ports is mastering a Knoppix CD. You can get a kiosk-style browser [mozdev.org] loaded with only your org's CA and a TLS client certificate. If you can distribute your o
Re: (Score:2)
Recommended keylengths/algorithms (Score:4, Informative)
You might want to have a look at http://www.keylength.com/ [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 ...
Rainbow tables? (Score:2)
Re: (Score:2)
User-chosen passwords are unlikely to be secure. One proposed solution is to generate secure keys for each user (a la ssh); there is then a problem of key distribution and of how to remember/carry and enter a key, which is itself nontrivial (lots of 2-factor authentication systems at least partially address this problem).
There are other possible solutions as well, but but if you're really paranoid then you absolutely don't want user-chosen passwords in any super-secure application. A major problem, of cou
Re: (Score:3)
I like Bruce, if that's enough. :)
And if you take your security with a grain of salt [wikipedia.org] they lose a lot of their byte. (ok, ok, I'll stop with the puns)
Re: (Score:2)
Salt makes it a non-issue when used correctly.
Re: (Score:2)
Salt makes it a non-issue when used correctly.
Sufficient salt defeats rainbow tables, but doesn't change the fact that most user-chosen passwords are crackable without tremendous effort.
Re:Rainbow tables? (Score:5, Informative)
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 [wikipedia.org]. 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.
Re: (Score:3)
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 si
Re: (Score:2)
Of course, this assumes that your salt and hashing scheme (pw first, then salt, or salt first then pw?) isn't stored in plain text files - like PHP scripts, etc.
Even if your salt string isn't stored and changes for every password, if how you compute the salted string to be hashed is visible in code, then it doesn't really matter....
Re:Rainbow tables? (Score:5, Informative)
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.
Re: (Score:2)
With salts in place, they wouldn't be creating "their own specialized rainbow table for the job." They would have to create N rainbow tables - one for each salt value. That's the point. You don't have one salt for your whole table, you should have one salt per hash. This makes it much more difficult to brute force the entire set of passwords at once (which is the point of a rainbow table).
I'm not saying you don't know this, but I wanted to clear this up for anyone who might read your statement and get confu
Re: (Score:2)
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.
If you can't reuse the table, it's not a rainbow table. Then it's simply a brute force attack.
Re: (Score:2)
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.
While this is true, you are effectively forcing the attacker to create a rainbow table for every possible salt value. Assuming that the salt value is different for each password (otherwise why store it in the database), you have forced the attacker back into using brute force.
Re: (Score:3)
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
Re:Rainbow tables? (Score:4, Informative)
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 [tarsnap.com]
Re: (Score:2)
Well, even if you picked a relatively-weak 128-bit hash, there are 340 billion, billion, billion, billion possible hashes. So that would be one heck of a table. And if the hash was salted, you'd need one such table for every possible salt. For a 160-bit hash like SHA1 with 32-bit salt, your rainbow table would need over six thousand billion, billion, billion, billion, billion, billion entries. If you had a billion computers each of which could calculate a billion, billion hashes per second, you could perhap
Windows XP is the bottleneck (Score:2)
Windows XP's crypto stack doesn't support any hash stronger than SHA-1, so if you have to worry about XP users, that's a big constraint.
Note that's for browsers/apps that use Windows native crypto stack. Browsers that include their own SSL implementation (Firefox and I believe Chrome too) can use whatever.
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.
I'm not sure I understand but here goes (Score:2)
Reading between the lines I'm assuming SHA-512 is the signature algorithm to sign the key and the author is just confused in thinking it effects encryption when it just applies to the effectiveness of chain validation and therefore the systems resistance to Active-MITM.
If this assumption is correct the right answer is to use whatever algorithm the signer above you used as you are limited by them as the weakest link. You gain nothing by rolling the dice with a dependancy on multiple signature algorithms.
Re: (Score:2)
SHA-512 is a one-way hashing algorithm, not a signing algorithm. It's main purpose (for passwords) is to allow you to store a representation of the password which can be compared with a future submission of the same password, to see if they are in fact the same. You can create a kind of signatures with such a hashing algorithm but what most people think of as "digital signatures" involves public/private key signatures. These signatures allow you to verify (roughly) "the person who controls the private key a
Re: (Score:2)
SHA-512 is a hashing algorithm that can be used to generate the hash that you actually sign with the low-level signature algorithm. To sign a digital certificate, you generate the secure hash of the 'inner certificate' (called a "TBS certificate" -- 'to be signed') and sign that, combining them to form the final, signed certificate. This is advantageous for a variety of reasons but it's necessary for one -- the low-level signature algorithm has a certain maximum length that it can sign and the certificate a
Encryption strength isn't important (Score:2)
Even though certain attacks are available against some hash algorithms, I am unaware of anyone ever successfully attacking an SSL protected server in the wild by attacking the encryption, head on, not the hash function or the public key encryption or the symmetrical key encryption.
However the main issue is as you mentioned trust, which in this case is obtained with certificates.
When I browse to an SSL enabled web site over https, I trust the web site operator, I trust the company who signed the certificate
Re: (Score:2)
I can't follow your claim. You say "breaking the encryption head on" but then say "not the hash function or the public key encryption or the symmetrical key encryption". Breaking the encryption head on would have to mean breaking either the PK encryption or the symmetrical key encryption since that's the only encryption there is.
In any event, it's obvious that historically breaking the encryption head on, particularly the symmetric encryption, was a real issue. That's why the NSA worked so hard to hold down
Sir, step away from the key generator (Score:5, Insightful)
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-
You're in over your head (Score:5, Insightful)
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.
Most times SSL is not the problem (Score:2)
Too late (Score:2)
Remember Ken Thompson C Compiler Backdoor (Score:3)
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
Re: (Score:2, Funny)
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
Well, building your computer from silicon yourself isn't enough. After all, how do you know the machines you used to fabricate your chips are not compromised? Maybe they don't produce exactly those chips which you designed? There's no way other than to build those machines yourself as well.
Oh, and don't make the mistake to use VHDL or similar to design your chips. Your VHDL compiler may be compromised, too. Only if you understand your chip down to the wire, you can be completely sure.
Well, provided that you
Deterrence (Score:2)
All security is about deterrence. As long as you're making your systems a less desirable target than others, you're doing enough. (There are some exceptions, e.g. those that are targeted for political reasons, who are going to be targeted no matter what. This may not apply to those.) Consider a bank vault: the classic example of real world security. The doors of modern bank vaults are so secure that it's generally easier to go through the wall of the vault than to try to "hack" the door. Technically,
Cryptographic Right Answers (from C. Percival) (Score:2)
The first thing to understand about SSL (Score:2)
Is that in the way SSL is typically implemented the crypto is not the main weakness. In a typical SSL setup the client verifies the server is who it says it is is by looking at a certificate chain and checking that chain against a list of "trusted" roots. The server then verifies the client is who it says it is by requesting a password or other credentials be transmitted across the encrypted channel (in the https case this happens in the form of a http post followed by http cookies).
The problem comes that i
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: (Score:2)
I don't think it would, since if they've got access to that, they've probably got access to the code, which will show what it is anyway.
Also, I think that's a good idea. Something I'll take on board in the future, me thinks.
Re: (Score:2)
Out of curiosity, is there a reason you'd store that as a prefix and not as a separate field?
Re: (Score:2)
>
Nothing wrong with using SHA-512, but it's not buying you 2^256 times extra security.
No, If in brute force(not feasable?) it is giving you only 2^128 times extra security.
Re: (Score:2)
I have to wonder whether the editors got trolled. Even beyond confusing a hash with a cipher, a number of things about the post seem to suggest it might have been crafted feigning total ignorance as a joke.
Re: (Score:2)
And I in turn wonder if I should be mad at the editors for letting a garbage story like this through, or agree with them that a person like this needs to be publicly thrown to the wolves.