Weak password storage

[GoogleCodeExporter]

The ESAPI reference implementation contains a weak salting mechanism for 
password storage. (Currently uses a known value, the account name) It also does 
not implement or encourage salt isolation.

Original issue reported on code.google.com by manico.james@gmail.com on 6 May 2011 at 8:11

[GoogleCodeExporter]

Original comment by manico.james@gmail.com on 29 May 2012 at 3:19

[GoogleCodeExporter]

I have a very simple suggestion (which I'm currently using). Double salting :

Add this line in the Authenicator.java

private static final String MASTERSALT = new 
String(ESAPI.securityConfiguration().getMasterSalt());

Replace hashPassword in implementation (e.g. FileBasedAuthentication) with 

public String hashPassword(String password, String accountName) throws 
EncryptionException {
        String salt = ESAPI.encryptor().hash(accountName.toLowerCase(), (String)MASTERSALT);
        return ESAPI.encryptor().hash(password, salt);
    }

The good thing with this method is that MasterSalt is available on 
ESAPI.properties, i.e. in a different place than the user database (in my case 
the user database is a mysql table). 

Original comment by michalis...@gmail.com on 26 Jun 2012 at 8:46

[GoogleCodeExporter]

This entire password storage mechanism in ESAPI is bunk. I suggest the move to 
PBKDF2, a more formal Key Derivation Function as well as very strong per-user 
random salting.

Original comment by j...@manico.net on 28 Mar 2014 at 12:46