[
https://issues.apache.org/jira/browse/SHIRO-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927675#action_12927675
]
Alan Cabrera commented on SHIRO-213:
------------------------------------
Yeah, # of hash iterations, etc., should be stored somewhere else. What I
usually do is to generate a random sting key to be used to index the # of hash
iterations, etc., and that is what gets stored w/ the hashed data is this key.
The same is true for encrypted data as well as well.
I'm not sure I would create VersionedSaltedAuthenticationInfo. I might create
a general class
class Hash {
private String key;
private byte[] hash;
}
class Encrypted
{
private String key;
private byte[] data;
}
> Password and hash management
> ----------------------------
>
> Key: SHIRO-213
> URL: https://issues.apache.org/jira/browse/SHIRO-213
> Project: Shiro
> Issue Type: New Feature
> Reporter: Alan Cabrera
>
> Sometimes secure hashes are long lived. I usually will hash something but
> prefix the string to be hashed with a secret password; I will usually add a
> bit of salt too. Often I will need to change the password to that hash on a
> periodic basis. Sometimes I find out that a particular hash algorithm is no
> longer secure and need to change my hash. What do I do with the old hashes?
> How can I tell them apart from the new ones?
> What I do is store the hashes as tuples which contain enough information my
> code to figure out what hash to use. All of this applies to encryption as
> well.
> I'm wondering is if we should provide some kind of manager to manage all
> this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
