About Markus Eisele

Markus is a Developer Advocate at Red Hat and focuses on JBoss Middleware. He is working with Java EE servers from different vendors since more than 14 years and talks about his favorite topics around Java EE on conferences all over the world. He has been a principle consultant and worked with different customers on all kinds of Java EE related applications and solutions. Beside that he has always been a prolific blogger, writer and tech editor for different Java EE related books. He is an active member of the German DOAG e.V. and it's representative on the iJUG e.V. As a Java Champion and former ACE Director he is well known in the community. Follow him on Twitter @myfear.

GlassFish JDBC Security with Salted Passwords on MySQL

One of the most successful posts on this blog is my post about setting up a JDBC Security Realm with form based authentication on GlassFish. Some comments on this post made me realize that there is more to do to actually make this secure as it should be.

GlassFish comes with a GlassFish JDBC Realm already. All you have to do is to initialize a database and get the security configuration right and you are done. Among the standard configuration you have the option to define a digest-algorithm (including encoding and charset). The digest-algorithm can be any JDK supported MessageDigest (MD2, MD5, SHA-1, SHA-256, SHA-384, SHA-512). Compare my JDBC Security Realm post for a complete setup.

What is weak or missing?

The out of the box solution goes a very trivial way. It simply hashes the password. There are many ways to recover passwords from plain hashes very quickly. The simplest way to crack a hash is to try to guess the password, hashing each guess, and checking if the guess’s hash equals the hash being cracked. If the hashes are equal, the guess is the password. The two most common ways of guessing passwords are dictionary attacks and brute-force attacks. Also very widely know are the Lookup tables. They are an effective method for cracking many hashes of the same type very quickly. The general idea is to pre-compute the hashes of the passwords in a password dictionary and store them, and their corresponding password, in a lookup table data structure. But we are not done now. You also find something called Reverse Lookup Tables. This attack allows an attacker to apply a dictionary or brute-force attack to many hashes at the same time, without having to pre-compute a lookup table. And last but not least the Rainbow Tables attack. They are like lookup tables, except that they sacrifice hash cracking speed to make the lookup tables smaller. Very impressive list of approaches. Clearly this doesn’t meet my personal need for securing passwords.

Adding some Salt

The above approaches work because of the fact that each password is hashed in the exact same way. Every time you run a password through the secure hash function it produces the exact same output. One way to prevent this is to add some salt to it. Appending or prepending a random string to the password before hashing it would solve this. This random string is referred to as “salt”. Be aware that reusing the salt for all passwords is not secure. You can still use rainbow tables or dictionary attacks to crack them. So you have to randomize the salt for every password and store it beside the hashed password. And it needs to change every time a user updates his password. A short sentence about length. Salts shouldn’t be too short. For the most effective length would be the same size as the password hash. If you use a SHA512 (512/8bit=64 bytes) you should choose a salt with at least 64 random bytes long.

Preparations

We are clearly leaving the standard JDBCRealm features now. Which means we have to implement our own security realm. Let’s call it UserRealm from now on. Let’s start with the same setup we have for the JDBCRealm. A MySQL database with a “jdbcrealmdb” schema. Only difference here, we prepare to save the salt with every password.

Now we implement the basic realm. The following code simply shows the mandatory members. I am going to make the source available during the next days. Until today this post is anything that is available for you.

I’m not exactly the kind of test driven guy but in this case it actually makes sense. Because the realm I am going to implement here doesn’t support user-management via the GlassFish admin console. So the basic requirement is to have a prepared database with all the users, passwords and salts in place. Let’s go. Add the sql-maven-plugin and let it create the tables during test-compile phase.

You can either use some db-unit magic to insert the test-data into your database or do this within your test-cases. I decided to go this way. First let us put all the relevant JDBC stuff to a separate place called SecurityStore. We basically need three methods. Add a user, get the salt for a user and validate the user.

Pretty easy, right? To be honest: Working with the byte[] could be hidden better, but I thought you will easier understand what is happening here. The salt() method returns a secure random salt of the configured length. The hashWithSalt() method puts everything into one SHA-512 hashed password.

A word about endcodings

I decided to Base64 encode it and I am using the proprietary API (sun.misc.BASE64Decoder, Encoder). You should think about using apache commons here. But it was the easiest way to do it. Another approach is to simply HEX encode (zero-pad) everything. The difference between Base64 and HEX is really just how bytes are represented. HEX is another way of saying “Base16”. HEX will take two characters for each byte – Base64 takes 4 characters for every 3 bytes, so it’s more efficient than hex. Assuming you’re using UTF-8 to encode the XML document, a 100K file will take 200K to encode in hex, or 133K in Base64.

And finally the missing method in the UserRealm

The very final part of this lengthy post is the authenticate method in the UserRealm class.

That is all left to do here. If we have a salt for a given user-name we generate a hashed password which we are going to check against the one we have in the database. The getSaltForUser() also is our implicit check for the existence of the user.

Making password cracks even harder: Slow Hash Functions

Security wouldn’t be called security if they wouldn’t add more to it. So, salted passwords are way better than simply hashed ones but still probably not enough because they still allow for brute-force or dictionary attacks on any individual hash. But you can add more protection. The keyword is key-stretching. Also known as slow hash functions. The idea here is to make computation slow enough to no longer allow for CPU/GPU driven attacks. It is implemented using a special CPU-intensive hash function. PBKDF2 (Password-Based Key Derivation Function 2) is one of them. You can use it in different ways but one warning: never try to do this at your own. Use one of the tested and provided implementations like the PBKDF2WithHmacSHA1 from the JDK or the PKCS5S2ParametersGenerator from the Bouncycastle library. An example could look like this:

We hear about password and user database leaks a lot. Every day. Some big sites have been hit and it basically is up to the implementer to provide suitable security for his users. Knowing where and how to tweak can be difficult and honestly using the provided features left you behind with a wrong comfortable feeling. Don’t stop learning about security features and keep an eye open for possible problems. I personally wish GlassFish would provide a more comprehensive set of default realms for users to work with. But as long as this isn’t the case my blog is the only way to guide you into the right direction. Hope you enjoyed it!

Join Us

With 1,240,600 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners. Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.