What are the Security Risks of Using Java Simplified Encryption Library?

Question

I have inherited code that is using the Java Simplified Encryption (Jasypt) Java Library. Specifically only the StandardPBEStringEncryptor Class.

import org.jasypt.encryption.pbe.StandardPBEStringEncryptor;

Are there any security risks with using the StandardPBEStringEncryptor Class? Is there a more secure alternative?

Answer 1

Are there any security risks with using the StandardPBEStringEncryptor Class

Jasypt doesn't actually implement any security or encryption algorithms, but instead delegates to other encryption providers. So there aren't any additional security risks that weren't already present in whichever library you are actually using underneath. I think by default, Jasypt uses the JCE (Java Cryptography Extension) that comes with Java.

Is there a more secure alternative?

Jasypt API can use other security providers including Bouncy Castle. Bouncy Castle has more algorithms that what comes with the JCE.

As stated in jasypt example

StandardPBEStringEncryptor myFirstEncryptor = new StandardPBEStringEncryptor();
myFirstEncryptor.setProvider(new BouncyCastleProvider());
myFirstEncryptor.setAlgorithm("PBEWITHSHA256AND128BITAES-CBC-BC");
myFirstEncryptor.setPassword(myPassword);

String myFirstEncryptedText = myFirstEncryptor.encrypt(myText);

Answer 2

The purpose of Jasypt is to encapsulate security best practices of using encryption technology so that people not familiar with encryption can be reasonably safe in deploying such technology. It makes choices about CBC vs ECB and 68bit vs 128bit vs 256 bit and other lower level details for you. Sometimes incorrect choices of these low level details can affect the security your application (read someone can crack it). Jaspyt helps to minimize such possibilities by giving you the best options for security. So in a way it's less risky than using JCE or Bouncy Castle directly.

In their FAQ they address your question directly:

http://www.jasypt.org/faq.html#does-jasypt-implement-algorithms

Answer 3

If the documentation article How to encrypt user passwords is anything to go by the code is likely acceptable but not up to date on current best practices as it recommends iterating SHA1 or MD5. While you could change the algorithms yourself to something like PBKDF2 or bcrypt, it's at least some sign that other parts may not be up to date as well.

Here's the thought experiment on why SHA1 isn't a good choice. What are MD5 and SHA-X optimized for? Definitely not slowness, which is exactly what you want from a password hashing algorithm. You don't want it to be quickly cracked, you want it to take time. Why You Shouldn't be using SHA1 or MD5 to Store Passwords

That being said you really don't want to roll this yourself either. Finding a good library or an expert can save you from some bad mistakes, which are easy to make using crypto. You're better off using that library than doing it yourself.