Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.0
    • Component/s: None
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          Les Hazlewood added a comment -

          Closing with the 1.2.0 release.

          Show
          Les Hazlewood added a comment - Closing with the 1.2.0 release.
          Hide
          Les Hazlewood added a comment -

          Implemented as part of SHIRO-280

          Show
          Les Hazlewood added a comment - Implemented as part of SHIRO-280
          Hide
          Les Hazlewood added a comment -

          Minor request - please open a thread on the dev list for these kinds of architectural/design discussions. It's a little 'noisy' to do this via Jira updates.

          Best,

          Les

          Show
          Les Hazlewood added a comment - Minor request - please open a thread on the dev list for these kinds of architectural/design discussions. It's a little 'noisy' to do this via Jira updates. Best, Les
          Hide
          Alan Cabrera added a comment -

          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; }
          Show
          Alan Cabrera added a comment - 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; }
          Hide
          Michael Kogan added a comment - - edited

          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?

          Show
          Michael Kogan added a comment - - edited 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?

            People

            • Assignee:
              Les Hazlewood
              Reporter:
              Alan Cabrera
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development