Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shiro.apache.org
Message-ID: <7453133.208321288736904154.JavaMail.jira@thor>
Date: Tue, 2 Nov 2010 18:28:24 -0400 (EDT)
From: "Michael Kogan (JIRA)" <jira@apache.org>
To: dev@shiro.apache.org
Subject: [jira] Issue Comment Edited: (SHIRO-213) Password and hash
 management
In-Reply-To: <17516563.164581288551626636.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SHIRO-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927645#action_12927645 ] 

Michael Kogan edited comment on SHIRO-213 at 11/2/10 6:27 PM:
--------------------------------------------------------------

Some thoughts as I am working on this for my project.

Assertion:
It is undesirable to store the number of hash iterations and to a lesser degree hash algorithm with the credentials.
I realize this is security-by-obscurity, but sometimes obscurity is enough.

Conclusion:
Use version information stored with the credentials, with the code interpreting the version's mapping to hashing algorithm and number of iterations.

Actions:

  * Add version to  SaltedAuthenticationInfo or create VersionedSaltedAuthenticationInfo
  * Hashed credentials matcher uses the version to look up the hashing algorithm and number of hash iterations in HashingManager
  * Create HashingManager class that given a version can return the hashing algorithm and number of hash iterations
  * Add HashingManager to Realm, allow it to be configured programtically or through ini

Any thoughts?


      was (Author: mike_k):
    Some thoughts as I am working on this for my project.

Assertion:
It is undesirable to store the number of hash iterations and to a lesser degree hash algorithm with the credentials.
I realize this is security-by-obscurity, but sometimes obscurity is enough.

Conclusion:
Use version information stored with the credentials, with the code interpreting the version's mapping to hashing algorithm and number of iterations.

Actions:

  * Add version to  SaltedAuthenticationInfo or create VersionedSaltedAuthenticationInfo
  * Hashed credentials matcher uses the version to look up the hashing algorithm and number of hash iterations in HashingManager
  * Create HashingManager class that given a version can return the hashing algorithm and number of hash iterations
  * Add HashingManager to SecurityManager, allow it to be configured programtically or through ini

Any thoughts?

  
> 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.