About Jasypt
Jasypt is Open Source Software created by a Spanish Software Engineer called Daniel Fernández in his spare time, and which has also received contributions of diverse kind from some other people.
It is neither made nor backed by any software (or any other type of) company, and it is offered to the public totally free of charge, both in binary and in source code forms, under the Apache License 2.0.
| [top] |
No, it doesn't, Jasypt by itself does not implement nor distribute in any of its forms any cryptographic algorithms, but it can use them via the Java Cryptography Extension.
| [top] |
Yes, all of its releases can be considered stable and production-ready.
| [top] |
No, it does not. Commercial support is not offered at the moment, but there are User Forums and Mailing Lists at your disposal.
| [top] |
In many ways:
If you want to contribute some code to Jasypt, please read first the page on Contributing to Jasypt.
| [top] |
Although Jasypt does not implement nor distribute in any of its forms any cryptographic algorithms, it can use them via the Java Cryptography Extension API and, as such, it is classified under ECCN code 5D002 and approved for export under License Exception TSU.
| [top] |
Jasypt is useful for many encryption tasks associated with applications, for example:
| [top] |
No. Jasypt does not implement any encryption algorithms, but instead delegates to the ones already provided by a JCE (Java Cryptography Extension) provider, which can be either the default VM one or any other of your choice, adding a layer for ease and correctness of use, configurability, integration with many other technologies, etc.
It is "simplified encryption" because it is much easier to use and integrate than the standard APIs, but you will get the same encryption power as if you were using the JCE API directly, or even more, as jasypt will enforce best practices and use standards that will ensure that you always get the highest level of security from encryption.
| [top] |
No, not at all. Jasypt offers some special configuration facilities to web applications, but it is not necessary for an application to be web for using jasypt. Jasypt will not add any dependency on any web-related API to your application if you don't want to.
| [top] |
Yes, you can. Jasypt provides an optional integration package for Hibernate, but it does not need Hibernate for normal operation. It won't add a dependency on Hibernate to your project.
| [top] |
Yes, you can. Jasypt is designed to be seamlessly integrated into a Spring-based application if required, but it does not depend on Spring in any way. It won't add a dependency on Spring to your project nor will force you to develop in an IoC-friendly manner.
| [top] |
Yes, you can. Jasypt provides an optional integration package for Spring Security, but it does not need Spring Security for normal operation.It won't add a dependency on Spring Security to your project.
| [top] |
Yes, since version 1.3, it can. The provider API in jasypt is open, so that you can use Bouncy Castle or any other JCE provider of your choice. You will only have to specify your provider to the encryptors or digesters you are using when configurig them.
But, Bouncy Castle is not required. Jasypt has no dependency on it, and thus you can decide not to use Bouncy Castle at all, for example if you want to use the algorithms shipped with your JVM's JCE default provider.
| [top] |
Yes and no. Jasypt by itself does not implement any algorithms, but it lets you use any JCE provider of your choice.
Both AES (encryption) and WHIRLPOOL (digests) are algorithms supported by the Bouncy Castle JCE provider, and thus you can use them from jasypt as long as you set Bouncy Castle as your JCE provider for your jasypt encryptors or digesters.
| [top] |
Digests are the results of applying cryptographic hash functions such as MD5, and are a type of one-way encryption. This means that an original input cannot be reconstructed from its digest, once it has been generated.
Password-based encryption is a type of bidirectional encryption, which means that encrypted data can be decypted to reconstruct the original input. Encryption is done by generating an encryption key, and passing it to an encryption algorithm such as DES. This key, in password-based encryption, is derived from a password set by the user (usually by a applying a digest algorithm to it).
| [top] |
Jasypt source trunks were merged in version 1.2, so that everything is now in a single module, jasypt. This has not affected the package structure, and you will find the jasypt-hibernate classes in package org.jasypt.hibernate and the jasypt-spring-security ones at org.jasypt.spring.security, as usual.
| [top] |
Well, first of all, if you are simply using a Message.digest() or a DigestUtils.md5() call to encrypt your passwords and store them in a database, you should know that your password system is much weaker than you think, and that acquiring access to your application could be easy for any attackers. And it even becomes worse as the number of users in your application increases.
If you want to learn why this happens and how you could try to avoid it, have a look at the article "How to encrypt user passwords".
...and, if you are not using such calls but some other APIs or techniques, maybe you should consider reading it anyway to know if jasypt can help you do things better.
If you are using Spring Security (former Acegi Security) for encrypting passwords in your application, check the corresponding question in this FAQ (below) to see what jasypt can do for you.
| [top] |
Before all, understand that jasypt is not a substitute for Spring Security / Acegi, which is a powerful and very complete security framework (and which use the Jasypt author truly recommends). Jasypt will instead integrate into Spring Security / Acegi and improve its password encoding capabilities.
Some reasons for considering this integration are:
For more information on integrating Jasypt into an Spring Security-enabled application, please check the Jasypt + Spring Security guide.
| [top] |
Simply use org.jasypt.util.password.BasicPasswordEncryptor. There is nothing more you need to know (if you don't want to :-)).
If you want more power (such as deciding which algorithm to use), then you can have a look at org.jasypt.digest.StandardStringDigester.
And if you want to know more, have a look at the article How to encrypt user passwords to learn about how a password should be encrypted.
| [top] |
If you have encrypted it using a message digesting technique, which is precisely what you should have done (by using a PasswordEncryptor implementation, StandardStringDigester or similar...), you cannot.
This is because digests are a one-way technique. Once you have created the digest, there is no way to reconstruct the original message (or password) back. To check if an input password matches a stored digest, the password is digested itself and then both digests are matched.
And why should passwords be encrypted in a way they cannot be decrypted? Because this is safest way to ensure that a password is known only to the user that created it, and that no one, not even system or database administrators, can know it.
| [top] |
Jasypt follows the RSA standards for the creation of digests (in fact, keys), specifically the use of both a (preferably random) salt and an iteration count.
The salt is an array of bytes (randomly and securely generated by default) which is added to the message prior to digest. The iteration count specifies how many times the hash function will be applied to the message.
This means that the process of digesting your passwords (or any other messages) with jasypt is not as simple (internally speaking) as just using MessageDigest, and because of this results look quite different.
For learning more about how password/message digesting works in jasypt, see Encrypting Passwords or the javadoc for StandardStringDigester.
For more info about the RSA standard, see PKCS #5: Password-Based Cryptography Standard.
| [top] |
If you are using a random salt generator (which is the default), yes, it is. It is normal and, specially if you are encrypting a password, it is good for you.
Using a random salt offers you several important security advantages as you can read in Encrypting Passwords, but if it is important for you that two digests of the same message be equal, you can set the salt size to 0 bytes or, if you prefer, use a different implementation of SaltGenerator.
A salt is also used for the obtention of keys for password-based encryption and so, when using a random salt generator (default), two password-based encryption results for the same original input will also differ. Nevertheless, this behaviour cannot be avoided in password-based encryption by setting a zero-byte long salt, as a salt is required by the PBE Java API itself. Thus, in this case you will have to use a fixed-salt SaltGenerator.
| [top] |
Of course. You see the use of salt and iteration count more thoroughly explained in jasypt documentation when referred to digests, but this is simply because many people wrongly (and dangerously) forget about using them when doing digests of, say, passwords. Thus, it seemed important to remark its use when digesting.
On the contrary, password-based encryption is usually done the right way, partly because the Java API for PBE enforces it to some extent. Anyway, jasypt offers you the advantage of transparently dealing with secure salt generation and checking.
For more info about the way password-based encryption should be done (and is done by jasypt), see see PKCS #5: Password-Based Cryptography Standard.
| [top] |
Because numbers are encrypted using the byte encryption support (encryption algorithms refer to bytes, not numbers), and so the result of encrypting a number will span a higher number of bytes than the original number. This provokes that a 4-byte integer needs no less than 16 bytes when it is in encrypted form.
Because of this, only BigIntegers and BigDecimals are supported in jasypt, as they provide arbitrary precision and so can handle such a big amount of bytes.
Nevertheless, if you are looking for hibernate encryption support for Longs, Doubles, Integers... jasypt provides support for encrypting them stored into SQL VARCHAR fields (instead of NUMERIC ones). Have a look at the Hibernate Integration Guide for further details.
| [top] |
You probably haven't added all the required dependencies to your classpath. Please check the Dependencies Page.
| [top] |
This is normal behaviour if you are using a random salt generator for your encryptor (which is the default). In this case, two different encryption operations on the same data should not return the same value (due to the use of a random salt). Because of this, none of the fields that are set to be encrypted when persisted can be a part of a WHERE clause in your search queries for the entity they belong to.
If you need to query encrypted fields, you should set a fixed salt generator to your encryptor, so that the same text encrypted twice will produce the same results. Although, be warned that this will only allow you to use that field in EQUALITY comparisons inside a WHERE clause, and that you will be reducing your level of security for that field.
| [top] |
This probably happens because you need download and install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files in order to be able to use strong-encryption algorithms like TripleDES.
| [top] |
EncryptionOperationNotPossibleException is a very general exception which jasypt raises whenever there is a problem with encryption or decryption operations. It does not provide any further information to prevent the encryption infrastructure from showing too much information about what is going on (we wouldn't want an attacker to get any algorithm-specific errors...)
When you get that error while decrypting, most of the times it will simply mean that the encrypted string you input was not adequate for the algorithm/password/keyObtentionIterations configuration you provided. Check that your encryptor is configured in exactly the same way as the one with which you originally encrypted the data.
| [top] |