Sorry - forgot the link references: [1] https://issues.apache.org/jira/browse/SHIRO-213 [2] https://issues.apache.org/jira/browse/SHIRO-279 [3] https://issues.apache.org/jira/browse/SHIRO-280 [4] http://en.wikipedia.org/wiki/Crypt_(Unix)
On Mon, Oct 3, 2011 at 8:06 PM, Les Hazlewood <[email protected]> wrote: > Hi all, > > I'm in the process of trying to finish up implementations for > SHIRO-213 [1], SHIRO-279 [2] and SHIRO-280 [3] (all related to > password management) in the form of a new PasswordService component. > > To convert a password hash into a String that can be used later to > compare passwords - even if the app's settings for hashes change over > time - that String needs to be formatted in such a way that the > original hash settings (salt, #iterations, algorithm name) can be > discovered and used to hash the provided password. Typically this is > handled by the Modular Crypt Format [4] and I've created a > Shiro-formated String that adheres to the MCF formatting. > > To compare passwords later, this process needs to be reversed, i.e. > formatted String -> hash parameters. I need a Java class to represent > the relevant information after reading the String. > > Our current Hash interface _could_ solve this need if we added two methods: > > ByteSource getSalt(); > int getIterations(); > > All of our existing Hash implementations already have access to this > data concepts during the hash - its just that those two fields are not > retained for later access after the hash operation is performed. If > we add those two methods, I can use our existing Hash classes to use > for the PasswordService's needs (i.e. String --> hash parameters, > which would be String --> Hash instance). > > Does anyone have any objections to or thoughts about these additions? > > Les
