4.2. Password encryption

GateIn uses PicketLink IDM framework to store information about identity objects (users/groups/memberships). See PicketLink IDM integration for more information. For better security, PicketLink IDM does not save user passwords into database in plain-text, but it uses CredentialEncoder which encodes password and saves the encoded form into the PicketLink IDM database.

Later, when a user wants to authenticate, he needs to provide his password in plain-text via the web login form. The provided password is then encoded and compared with encoded password from the PicketLink IDM database. GateIn is then able to authenticate user based on this comparison.

Default implementation of CredentialEncoder is using password hashing with MD5 algorithm and storing those MD5 hashes in database. It does not use any salting of passwords. This is not the safest solution, but it is backward compatible with previous releases of GateIn Portal before version 3.5, where MD5 password hashing was only possible encoding form. So if you migrate from older release of GateIn Portal, your users will be still able to authenticate.

However, if you are starting from fresh database (no migration from previous GateIn releases), you may increase security by using better hashing algorithm and especially by enabling password salting. See below for details of various implementations of CredentialEncoder, knowing that they are configured in PicketLink IDM configuration file, which is usually portal.war/WEB-INF/conf/organization/picketlink-idm/picketlink-idm-config.xml.

HashingEncoder

This is the default choice. It uses only hashing of passwords with MD5 algorithm without salting. It uses only hashing of passwords with MD5 algorithm without salting. As mentioned previously, it is not the safest solution but it is backward compatible with previous GateIn releases, so there is no issue related to database migration from previous releases. Configuration looks like this:


<option>
    <name>credentialEncoder.class</name>
    <value>org.picketlink.idm.impl.credential.HashingEncoder</value>
</option>
<option>
    <name>credentialEncoder.hashAlgorithm</name>
    <value>MD5</value>
</option>

DatabaseReadingSaltEncoder

This implementation provides salting of password in addition to hashing. The salt is unique for each user, so it is much more complicated to decrypt password via brute force, if one attacker steals encoded passwords from your database. The salt is generated randomly for each user and stored in PicketLink IDM database as attribute. Random generation of salt ensures that all users have different salts, so even if two users have the same password, the encoded password in database will be different for them. Here is configuration example, which is using SHA-256 algorithm for hashing (more secure than MD5) and algorithm SHA1PRNG for generation of random salts:


<option>
    <name>credentialEncoder.class</name>
    <value>org.picketlink.idm.impl.credential.DatabaseReadingSaltEncoder</value>
</option>
<option>
    <name>credentialEncoder.hashAlgorithm</name>
    <value>SHA-256</value>
</option>
<option>
    <name>credentialEncoder.secureRandomAlgorithm</name>
    <value>SHA1PRNG</value>
</option>

FileReadingSaltEncoder

It also uses hashing and salting, so it is similar to the previous encoder. But it is theoretically even more secure, because salts are not stored in PicketLink IDM database with passwords. Salt of each user is generated from saltPrefix and username. And saltPrefix is read from some files in your filesystem. Configuration may look like this:


<option>
    <name>credentialEncoder.class</name>
    <value>org.picketlink.idm.impl.credential.FileReadingSaltEncoder</value>
</option>
<option>
    <name>credentialEncoder.hashAlgorithm</name>
    <value>SHA-256</value>
</option>
<option>
    <name>credentialEncoder.fileLocation</name>
    <value>/salt/mysalt.txt</value>
</option>

Please note that the /salt/mysalt.txt file must exist and must be readable by the user who runs GateIn, whereas it should not be readable by other users of your OS. The file can have some random content phrases, for example: a4564dac2aasddsklklkajdgnioiow.

So the FileReadingSaltEncoder is probably the most secure of all options; but in addition to DatabaseReadingSaltEncoder, you need to set the file with salt.

Note

The CredentialEncoder from above is actually used only for encoding of passwords in PicketLink IDM database. It is not used for LDAP. PicketLink IDM LDAP implementation (LDAPIdentityStore) is sending passwords to LDAP server in plain form, because password encoding is usually provided by LDAP server itself. For example, OpenDS 2 uses SHA1 based hashing of passwords with random generation of user salt (so actually something similar to the DatabaseReadingSaltEncoder implementation).

See also

Copyright ©. All rights reserved. eXo Platform SAS
blog comments powered byDisqus