Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0
    • Fix Version/s: None
    • Labels:
    • Environment:

      All

      Description

      After some quick testing using the latest stable version of JamWiki, I see that the user passwords are stored in the database as the same hashed value if the password string is the same. It would be much better if a unique salt was generated for each password.

        Activity

        Hide
        Ryan Holliday
        added a comment -

        Unfortunately my experience with encryption is limited to the basics, so does https://www.owasp.org/index.php/Hashing_Java ("Why add salt?" section) adequately describe a proper solution? In that case it looks like the suggested solution is to store a random salt for each user in plain text, and to then use that salt to encrypt/hash the password. If so then this could probably be implemented fairly easily for JAMWiki 1.2, and the fallback behavior for legacy users without a "stored_salt" value would be to use the current (shared) salt; creating a new account or updating an existing password would trigger a new "stored_salt" value to be saved. Does that sound sufficient?

        Show
        Ryan Holliday
        added a comment - Unfortunately my experience with encryption is limited to the basics, so does https://www.owasp.org/index.php/Hashing_Java ("Why add salt?" section) adequately describe a proper solution? In that case it looks like the suggested solution is to store a random salt for each user in plain text, and to then use that salt to encrypt/hash the password. If so then this could probably be implemented fairly easily for JAMWiki 1.2, and the fallback behavior for legacy users without a "stored_salt" value would be to use the current (shared) salt; creating a new account or updating an existing password would trigger a new "stored_salt" value to be saved. Does that sound sufficient?
        Hide
        Adam Lesperance
        added a comment -

        If you wanted to roll your own solution that would be fine. I would highly recommend you look into using Jasypt (http://www.jasypt.org/springsecurity.html) though since it integrates very nicely with sprint security and handles pretty much everything for you.

        Show
        Adam Lesperance
        added a comment - If you wanted to roll your own solution that would be fine. I would highly recommend you look into using Jasypt ( http://www.jasypt.org/springsecurity.html ) though since it integrates very nicely with sprint security and handles pretty much everything for you.
        Hide
        Ryan Holliday
        added a comment -

        Thanks for the pointer - provided Jasypt can be integrated in a way that is backwards-compatible with existing data then this looks like something that can definitely be included in JAMWiki 1.2. And even if Jasypt can't be integrated due to legacy issues, improved salts look doable for the next major release and I've added it to the roadmap at http://jamwiki.org/wiki/en/Tech:JAMWiki_1.2.

        Show
        Ryan Holliday
        added a comment - Thanks for the pointer - provided Jasypt can be integrated in a way that is backwards-compatible with existing data then this looks like something that can definitely be included in JAMWiki 1.2. And even if Jasypt can't be integrated due to legacy issues, improved salts look doable for the next major release and I've added it to the roadmap at http://jamwiki.org/wiki/en/Tech:JAMWiki_1.2 .

          People

          • Assignee:
            Ryan Holliday
            Reporter:
            Adam Lesperance
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: