new JDBCHashStrategy()
Determines how the hashing is computed in the implementation
You can implement this to provide a different hashing strategy to the default.
Methods
computeHash(password, salt, version) → {string}
Compute the hashed password given the unhashed password and the salt
Parameters:
| Name | Type | Description |
|---|---|---|
password |
string | the unhashed password |
salt |
string | the salt |
version |
number | the nonce version to use |
Returns:
the hashed password
- Type
- string
generateSalt() → {string}
Compute a random salt.
Returns:
a non null salt value
- Type
- string
getHashedStoredPwd(row) → {string}
Retrieve the hashed password from the result of the authentication query
Parameters:
| Name | Type | Description |
|---|---|---|
row |
todo | the row |
Returns:
the hashed password
- Type
- string
getSalt(row) → {string}
Retrieve the salt from the result of the authentication query
Parameters:
| Name | Type | Description |
|---|---|---|
row |
todo | the row |
Returns:
the salt
- Type
- string
setNonces(nonces)
Sets a ordered list of nonces where each position corresponds to a version.
The nonces are supposed not to be stored in the underlying jdbc storage but to
be provided as a application configuration. The idea is to add one extra variable
to the hash function in order to make breaking the passwords using rainbow tables
or precomputed hashes harder. Leaving the attacker only with the brute force
approach.
Nonces are dependent on the implementation. E.g.: for the SHA512 they are extra salt
used during the hashing, for the PBKDF2 they map the number of iterations the algorithm
should take
Parameters:
| Name | Type | Description |
|---|---|---|
nonces |
todo | a json array. |