Another thought:
>From http://tools.ietf.org/html/rfc2898#page-6 PKCS#5 rfc2898 section 4.1
(Salt):
For instance, the salt could have
an additional non-random octet that specifies the purpose of
the derived key. Alternatively, it could be the encoding of a
structure that specifies detailed information about the derived
key, such as the encryption or authentication technique and a
sequence number among the different keys derived from the
password. The particular format of the additional data is left
to the application.
I wonder if this suggestion makes for a reasonable approach for salt:
Allow the first byte of the salt to be interpreted by a user-provided class
that implements a simple Shiro interface.
Of course it is more transparent and simple to have some sort of
configuration in the data store specifying how the the password was hashed -
algorithm, number of iterations, but it seems to me there is some value in
the attacker with access to hashed passwords and salt values not knowing
that information.
--
View this message in context:
http://shiro-developer.582600.n2.nabble.com/Password-and-hash-management-tp5667050p5695239.html
Sent from the Shiro Developer mailing list archive at Nabble.com.
