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
