0

We are currently working on authentication for a web application. For password storage, we're using Jasypt StrongPasswordEncryptor with SHA-256 and tens of thousands of iterations. Going into the project, I had hoped to implement PBKDF2-HMAC-SHA512 (I do not believe I could get traction on a switch to bcrypt or scrypt).

The Jasypt StrongPasswordEncryptor simply re-hashes the passed however many times specified using SHA-256 (or other algorithm chosen), instead of the HMAC iterations in PBKDF2. I understand that the security benefit of PBKDF2 is its slow speed, while SHA is fast. However, since PBKDF2 is simply reiterating HMAC-SHA (or some other function), it's hard to show an improvement over the current method.

If the security improvement from the change is minimal, it is unlikely to be done. If there is a substantial security improvement, it's still early enough in the project to be made.

What is it about HMAC-SHA that makes it better/slower than a normal SHA?

What sort of information can I bring to a change request - how much of an improvement would there be?

Is the change necessary?

Applesnacks
  • 3
  • 1
  • 3

1 Answers1

3

Jasypt's StrongPasswordEncryptor is a special case of Jasypt's StandardStringDigester that, despite its name, is not standard at all. From the description, it appears to be some custom construction, which thus has the same problem than any other non-standard construction: it has not been reviewed. We don't know how to design secure functions, and the best we can do is to put functions under the collective scrutiny of (many) cryptographers for some time (years). A non-standard function did not benefit from even that, so we really don't know if it is good or not.

Not following peer-reviewed standards is, in my opinion, a serious security defect. Switching to PBKDF2 would thus be a significant improvement. (But I predict that people who indulge in custom functions will think otherwise.)

Of course, bcrypt is better.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Couldn't have said it better. If no one has looked at it, how can you gage its security? I doubt that the speed is really the reason for not using PBKDF2 since a good amount of people seemingly like it http://en.wikipedia.org/wiki/PBKDF2#Systems_that_use_PBKDF2. – RoraΖ Aug 12 '14 at 18:40
  • I can run with that. I hope that the product team can be convinced by that. As a point of personal curiosity (and maybe an additional argument if needed), is there a specific problem with the Jasypt scheme, or a specific reason why the HMAC-SHA re-tierations of PBKDF2 are better? I acknowledge that a non-standard implementation is a problem with the scheme, but non-security focused developers with a time-crunch may not be willing to adjust for that reason alone. – Applesnacks Aug 12 '14 at 19:04
  • I don't see anything blatantly wrong with their "iterated hash", although it has the same weakness as PBKDF2 with SHA-1/SHA-256, namely that it can be optimized big time on GPU (GPU are extremely good at that kind of 32-bit operations used in SHA-1 or SHA-256). The switch the PBKDF2/SHA-512 increases practical security because of "SHA-512", not because of "PBKDF2". But bcrypt would be even better (it is _really_ hostile to GPU). – Thomas Pornin Aug 12 '14 at 19:32
  • @Applesnacks: It also does not say whether or not `matches` uses a constant-time comparison. –  Aug 12 '14 at 19:36