GlassFish JDBC Security with Salted Passwords on MySQL
Join the DZone community and get the full member experience.
Join For FreeSecurity 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:
publicSecurityStore(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, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments