SQL Zone is brought to you in partnership with:

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 the Java Community leader 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. Markus is a DZone MVB and is not an employee of DZone and has posted 195 posts at DZone. You can read more from them at their website. View Full User Profile

GlassFish JDBC Security with Salted Passwords on MySQL

07.31.2012
| 3885 views |
  • submit to reddit
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.

Security out of the box
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/ 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.

USE jdbcrealmdb; CREATE TABLE `jdbcrealmdb`.`users` ( `username` varchar(255) NOT NULL, `salt` varchar(255) NOT NULL, `password` varchar(255) DEFAULT NULL, PRIMARY KEY (`username`) ) DEFAULT ;     CREATE TABLE `jdbcrealmdb`.`groups` ( `username` varchar(255) DEFAULT NULL, `groupname` varchar(255) DEFAULT NULL) DEFAULT ; CREATE INDEX groups_users_FK1 ON groups(username ASC);

Now we implement the basic realm. The following code simply shows the mandatory members. I am going to make the source available on github.com.

publicclassUserRealm extendsAppservRealm { /** * Init realm from properties */ protectedvoidinit(Properties props) /** * Get JAASContext */ publicString getJAASContext() /** * Get AuthType */ publicString getAuthType() /** * Get DB Connection */ privateConnection getConnection() /** * Close Connection */ privatevoidcloseConnection(Connection cn) /** * Close prepared statement */ privatevoidcloseStatement(PreparedStatement st) /** * Make the compiler happy. */ publicEnumeration getGroupNames(String string) /** * Authenticate the user */ publicString[] authenticate(String userId, String password) }

But the most important part is missing here.

Setting up some tests
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.

<plugin>  <groupId>org.codehaus.mojo</groupId>  <artifactId>sql-maven-plugin</artifactId>  <version>1.3</version>  <dependencies>  <dependency>  <groupId>mysql</groupId>  <artifactId>mysql-connector-java</artifactId>  <version>5.1.18</version>  </dependency>  </dependencies>  <configuration>  <driver>${driver}</driver>  <url>${url}</url>  <username>${username}</username>  <password>${password}</password>  <skip>${maven.test.skip}</skip>  <srcFiles>  <srcFile>src/test/data/drop-and-create-table.sql</srcFile>  </srcFiles>  </configuration>  <executions>  <execution>  <id>create-table</id>  <phase>test-compile</phase>  <goals>  <goal>execute</goal>  </goals>  </execution>  </executions>  </plugin>

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.

privatefinalstaticString ADD_USER = "INSERT INTO users VALUES(?,?,?);";  privatefinalstaticString SALT_FOR_USER = "SELECT salt FROM users u WHERE username = ?;";  privatefinalstaticString VERIFY_USER = "SELECT username FROM users u WHERE username = ? AND password = ?;"; //... publicvoidaddUser(String name, String salt, String password) {  try{  PreparedStatement (ADD_USER);  pstm.setString(1, name);  pstm.setString(2, salt);  pstm.setString(3, password);  pstm.executeUpdate();  } catch(SQLException ex) {  LOGGER.log(Level.SEVERE, "Create User failed!", ex);  }  }    publicString getSaltForUser(String name) {  String salt = null;  try{  PreparedStatement (SALT_FOR_USER);  pstm.setString(1, name);  ResultSet ();    if(rs.next()) {  (1);  }    } catch(SQLException ex) {  LOGGER.log(Level.SEVERE, "User not found!", ex);  }  returnsalt;  }    publicbooleanvalidateUser(String name, String password) {  try{  PreparedStatement (VERIFY_USER);  pstm.setString(1, name);  pstm.setString(2, password);  ResultSet ();  if(rs.next()) {  returntrue;  }  } catch(SQLException ex) {  LOGGER.log(Level.SEVERE, "User validation failed!", ex);  }  returnfalse;  }
In order to not implement too much here I decided to have two separate constructors:

public
SecurityStore(String dataSource) publicSecurityStore(String user, String passwd)

So this will work with both, the app-server and my local tests. Next is the actual password and salt logic.

Working with Passwords, Hashes and Salts
Here is what I came up with:

publicclassPassword {    privateSecureRandom random;  privatestaticfinalString CHARSET = "UTF-8";  privatestaticfinalString ENCRYPTION_ALGORITHM = "SHA-512";  privateBASE64Decoder decoder = newBASE64Decoder();  privateBASE64Encoder encoder = newBASE64Encoder();    publicbyte[] getSalt(intlength) {  random = newSecureRandom();  bytebytes[] = newbyte[length];  random.nextBytes(bytes);  returnbytes;  }    publicbyte[] hashWithSalt(String password, byte[] salt) {  byte[] hash = null;  try{  byte[] (CHARSET);  MessageDigest md;  (ENCRYPTION_ALGORITHM);  md.reset();  md.update(salt);  md.update(bytesOfMessage);  ();    } catch(UnsupportedEncodingException | NoSuchAlgorithmException ex) {  Logger.getLogger(Password.class.getName()).log(Level.SEVERE, "Encoding Problem", ex);  }  returnhash;  }    publicString base64FromBytes(byte[] text) {  returnencoder.encode(text);  }    publicbyte[] bytesFrombase64(String text) {  byte[] textBytes = null;  try{  (text);  } catch(IOException ex) {  Logger.getLogger(Password.class.getName()).log(Level.SEVERE, "Encoding failed!", ex);  }  returntextBytes;  } }

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.

/**  * Authenticates a user against GlassFish  *  * @param name The user name  * @param givenPwd The password to check  * @return String[] of the groups a user belongs to.  * @throws Exception  */ publicString[] authenticate(String name, String givenPwd) throwsException {  SecurityStore store = newSecurityStore(dataSource);  // attempting to read the users-salt  String (name);    // Defaulting to a failed login by setting null  String[] result = null;    if(salt != null) {  Password pwd = newPassword();  // get the byte[] from the salt  byte[] (salt);  // hash password and salt  byte[] (givenPwd, saltBytes);  // Base64 encode to String  String (passwordBytes);  _logger.log(Level.FINE, "PWD Generated {0}", password);  // validate password with the db  if(store.validateUser(name, password)) {  result[0] = "ValidUser";  }  }  returnresult; }

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:

publicbyte[] hashWithSlowsalt(String password, byte[] salt) {  SecretKeyFactory factory;  Key key = null;  try{  ("PBKDF2WithHmacSHA1");  KeySpec keyspec = newPBEKeySpec(password.toCharArray(), salt, 1000, 512);  (keyspec);  } catch(NoSuchAlgorithmException | InvalidKeySpecException ex) {  Logger.getLogger(Password.class.getName()).log(Level.SEVERE, null, ex);  }  returnkey.getEncoded(); }

Why all that?
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!

[UPDATE 31.07.2012]
The source is on github.com 



Published at DZone with permission of Markus Eisele, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)