Binary encryption support. Jasypt allows the digest and encryption of binaries (byte arrays). Encrypt your objects or files when needed (for being sent over the net, for example).

Number encryption support. Besides texts and binaries, it allows the digest and encryption of numeric values (BigInteger and BigDecimal, other numeric types are supported when encrypting for Hibernate persistence).

Completely thread-safe.

Provides both easy, no-configuration encryption tools for users new to encryption, and also highly configurable standard encryption tools, for power-users.

Hibernate 3 optional integration for persisting fields of your mapped entities in an encrypted manner. Encryption of fields is defined in the Hibernate mapping files, and it remains transparent for the rest of the application (useful for sensitive personal data, databases with many read-enabled users...). Encrypt texts, binaries, numbers, booleans, dates...

Seamlessly integrable into a Spring application. All the digesters and encryptors in jasypt are designed to be easily used (instantiated, dependency-injected...) from Spring. And, because of their being thread-safe, they can be used without synchronization worries in a singleton-oriented environment like Spring.

Spring Security (Acegi Security) optional integration for performing password encryption and matching tasks for the security framework, improving the security of your users' passwords by using safer password encryption mechanisms and providing you with a higher degree of configuration and control.

Provides advanced functionality for encrypting all or part of an application's configuration files, including sensitive information like database passwords. Seamlessly integrate encrypted configuration into plain, Spring-based and/or Hibernate-enabled applications.

Provides easy to use CLI (Command Line Interface) tools to allow developers initialize their encrypted data and include encryption/decryption/digest operations in maintenance tasks or scripts.

Integrates into Apache Wicket, for more robust encryption of URLs in your secure applications.

Comprehensive guides and javadoc documentation, to allow developers to better understand what they are really doing to their data.

Robust charset support, designed to adequately encrypt and digest texts whichever the original charset is. Complete support for languages like Japanese, Korean, Arabic... with no encoding or platform issues.

Very high level of configuration capabilities: The developer can implement tricks like instructing an "encryptor" to ask a, for example, remote HTTPS server for the password to be used for encryption. It lets you meet your security needs.

I have not tried this library out yet, but as long as it works I think it fills a huge need. I always cringe when I see usernames and passwords to all the databases and LDAP server sitting in plain text files sitting out in file systems and version control systems.

Encrypting config files is a bit like chasing your tail. You end up with a key or algorithm that needs to be protected, so you've not solved the problem, just moved it. Ultimately you're still relying on O/S or hardware level security, you just feel better about it because the credentials aren't human readable.

Moving the problem to one password that can be stored as a variable, file, or entered at application boot time, is more manageable, and IMO more secure.

You'd better encrypt that file then. But where to put the password for that?

With Jasypt, you can just make an admin enter it at deployment time :-):

That's nice for certain situations, I'm sure, but in my case, anything that I would encrypt would be something only the administrators should know anyway. Maybe if you have different administrators that should know different passwords this would make sense.
My experience is that these kinds of things are generally insecure. I used to use a tool that would allow you to encrypt passwords in your 'code'. Then you could run it and the developers theoretically couldn't see the passwords. But all I had to do was use that property as something like an email host and when it failed to connect, it would display the value of the password as the host name it could not reach in the log. I'm not saying that you can't address these issues because I can see some ways that you could but I have to agree with the poster above that this kind of thing tends to give a false sense of security.

We have been using the Jasypt framework for a bit more than a year and its pretty good. Very easy to integrate, configure and extend to suit your own needs.
Few things though:
- Hibernate integration: you have to think a bit about your solution if you wanna encrypt PK-FK relationships, no out of the box solution... (yet?)
- In a development environment you probably don't want to use the PBE Filter + Servlet until deployment time. If you do, you probably want to automate the initialization of the PBE system at startup from a props file via a servlet listener or something..
Great tool... Good work :)
/Mike

- Hibernate integration: you have to think a bit about your solution if you wanna encrypt PK-FK relationships, no out of the box solution... (yet?)

Well, there is no solution to do it transparently in a Hibernate-integrated manner, you are right (although you could do it manually).
But... what would this really add? I mean, both sides (FK and PK) would have to be encrypted in exactly the same manner so that they maintain referential integrity... the relation betweeen tuples in the two tables would still be clearly identifiable...
If it is just a matter of not showing the values of the keys (maybe useful with natural keys)... as I say, you would have to do it manually. But I will keep this in mind for next versions, thanks.

- In a development environment you probably don't want to use the PBE Filter + Servlet until deployment time. If you do, you probably want to automate the initialization of the PBE system at startup from a props file via a servlet listener or something..

Happened to me too during testing :-) Maybe in the future I look for a solution to this, but we would have to be very careful here if we don't want the user to go production without switching again to "normal behaviour"...
If you have more questions or comments, please don't hesitate to ask in the user forums and mailing lists at the Jasypt website.
Regards,
Daniel.

I never understood why people store login information for a datasource in properties files. It's inflexible, and JEE has a perfectly good working solution for this: jndi datasources.
Also, why not just store configuration in a simple database table with 2 (or 3) columns: property, value and perhaps server, where you can set server specific overwrites.
This is the way I've always done it, and it has served me well so far.
Oh by the way, the login page title on TSS says:
Kinda ugly don't you think?
Joris

You are fortunate that you've never worked with a non-JEE application, then.
I've worked on a couple where we've ended up writing something like this ourselves.
I'll definitely bookmark this on the off chance that I run into a situation where I need it. Thanks!
Peter Mularien

I never understood why people store login information for a datasource in properties files. It's inflexible, and JEE has a perfectly good working solution for this: jndi datasources.

Also, why not just store configuration in a simple database table with 2 (or 3) columns: property, value and perhaps server, where you can set server specific overwrites.

This is the way I've always done it, and it has served me well so far.

Oh by the way, the login page title on TSS says: Kinda ugly don't you think?

Joris

That is fine if you are in a J2EE environment, using a database, and working with a J2EE server that encrypts datasource passwords in it's xml files.
For people that don't fit the above you are either going to have to encrypt your passwords, or leave them laying around somewhere. I have worked with the encryption classes directly and they are not hard to use, but this api looks a lot more convenient.

I once was on a project where the error codes were used and placed into a table on the database. When there was an issue getting to the database, the users would get a "something happened" error because the error message "database unavailable" was in the database.
Personally, I think that in general, the database is actually a pretty terrible place for configuration. It's much easier to test and deploy to different environments when you can keep your configuration to yourself. I've not seen a whole lot of benefit from database based configuration even though that's normally what I've worked with.
On the subject of the post, I don't see a lot of reason to encrypt configurations in my universe. If we need to configure passwords, we can just create special password files that maintained by administrators and use file access rights to prevent the unauthorized from viewing them.

I can only hope that this won't be used much. Imaging those big Spring XML configuration files (already pretty cryptic), made even tougher to deal with with encryption.
Don't get me wrong, I can see some scenarios or installations that can use this kind of functionality, but I just hope that most try to deal with security issues from other angles, rather than encrypting everything.
Regards,
Paul Casal
Sr Developer - jbilling.com
The Enterprise Open Source Billing System

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.