2

Good rule of thumb: If you need encryption, don't do it yourself. You'll get it wrong!

So far so good. I was looking at Jasypt for that reason. it claims to do all the complicated stuff for you, without you needing to understand it. It offers you a class with the trustworthy name StrongPasswordEncryptor:

Utility class for easily performing high-strength password digesting and checking.

Still I wanted to know more about what it does, before I trust my users passwords to it. As it claims in the API:

This class internally holds a StandardStringDigester configured this way:

  • Algorithm: SHA-256.
  • Salt size: 16 bytes.
  • Iterations: 100000.

And that's were my basic knowledge on that topic tells me: That's not how you should do it!

In fact it looks to me like a naive approach. Take SHA, because MD5 is not secure any more, but better take one with a bigger number, because bigger is better there. But multiple bytes of salt in there and then run it lots of times to be harder to crack.

Why do I think that is bad? SHA is basically designed to be an elaborated kind of check digit. It is meant to be fast. That is the opposite of what you want of a password hashing algorithm. You want those to be cost expansive even on hardware designed to be fast on them. In fact there is a lot of discourse on the web who good bcrypt and PBKDF2 lack some important requirements and if scrpyt should be used instead. Look at these stackexchange questions to get an idea: https://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage, SHA512 vs. Blowfish and Bcrypt

To give a quote from http://www.jasypt.org/howtoencryptuserpasswords.html

In most cases, both MD5 or SHA-1 will be adequate choices for password digesting, although applying these algorithms will not be enough, as we will see later on.

I'm passionally disagreeing in that point, because of the reasons above.

Am I missing something here, or is Jasypt really selling me a fundamentally flawed algorithm under the name StrongPasswordEncryptor? Because if it does, I don't want to trust that library with my most sensitive data.

I know, I could just decide to simply not use it, but because of my rule of thumb I mentioned at the beginning, I'd like to have my evaluation checked by people with understanding in password encryption.

Community
  • 1
  • 1
kratenko
  • 6,652
  • 4
  • 32
  • 57
  • Just to clarify a point. You do not want your secure hashing function to be slow by default. You want the OPTION to make it slow, usually be increasing some kind of internal iteration it does. – Jazzepi Nov 28 '14 at 14:58
  • One point of a good hashing algorithm should be its speed! While SHA is and should be very fast in one iteration, the so called "stretching" is what makes your stored password expensive to bruteforce. The hashing algorithm by default should not be slow to be secure for password hashing. – luuksen Nov 28 '14 at 15:02
  • This question will illicit a lot of opinion-based answers... – Buggabill Nov 28 '14 at 15:06
  • @Jazzepi Sure, but I want it to be *sure* to be slow (by configuration), so that no special IC-Chip will be that much faster. One such idea is making the algorithm memory expansive, so it's not easily possible to build a computer that calculates 100k hashs in parallel with 100k cpu-cores; at least not with tons of mem. That's why scrpyt has been created afaik, see http://en.wikipedia.org/wiki/Scrypt#Introduction – kratenko Nov 28 '14 at 15:06
  • @Buggabill I'm afraid so, too. But I think it has a legit point in it. And it is a concern to me right now, because I'm somewhat asked for advise... – kratenko Nov 28 '14 at 15:09
  • The advantages of PBKDF2 over simpler salted iterated hashes are rather theoretical. I can't say much without looking at the concrete algorithm, but I'd expect it to be as strong as PBKDF2-HMAC-SHA-2 with the equivalent number of iterations and weaker than bcrypt and scrypt at similar cost. – CodesInChaos Nov 28 '14 at 15:37

0 Answers0