Derby
  1. Derby
  2. DERBY-5539

Harden password hashing in the builtin authentication service

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.9.1.0
    • Fix Version/s: 10.9.1.0
    • Component/s: Services
    • Labels:
      None
    • Bug behavior facts:
      Security

      Description

      The Open Web Application Security Project has some suggestions on how to make it harder for an attacker to crack hashed passwords: https://www.owasp.org/index.php/Hashing_Java

      The builtin authentication service doesn't follow all the suggestions. In particular, it doesn't add a random salt, and it only performs the hash operation once.

      I propose that we add two new properties that makes it possible to configure builtin to use a random salt and run multiple iterations of the hash operation:

      • derby.authentication.builtin.saltLength - the length of the random salt to add (in bytes)
      • derby.authentication.builtin.iterations - the number of times to perform the hash operation

      I'd also suggest that we set the defaults so that random salt and multiple iterations are used by default. The OWASP page mentions 64 bits of salt (8 bytes) and a minimum of 1000 iterations. I consulted a security expert who thought that these recommendations sounded OK, but he believed the recommended salt length was likely to be revised and suggested 16 bytes instead. The only price we pay by going from 8 to 16 bytes, is that we'll need to store 8 bytes extra per user in the database, so I don't see any reason not to set the default for derby.authentication.builtin.saltLength as high as 16. Setting the default for derby.authentication.builtin.iterations to 1000 will make authentication of a user somewhat slower (which is the point, really), but experiments on my machine suggest that running our default hash function (SHA-256) 1000 times takes around 1 ms. Since authentication only happens when establishing a new connection to the database, that would be a negligible cost, I think.

      If saltLength is set to 0 and iterations is set to 1, the hashing will be done in the exact same way as in previous versions.

      Both of the properties should only be respected when the data dictionary version is 10.9 or higher, so that users in soft-upgraded databases can still log in after a downgrade.

      1. d5539-2a.diff
        4 kB
        Knut Anders Hatlen
      2. d5539-1b.diff
        34 kB
        Knut Anders Hatlen
      3. d5539-1a.diff
        34 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Gavin made changes -
          Workflow jira [ 12646003 ] Default workflow, editable Closed status [ 12797032 ]
          Knut Anders Hatlen made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Knut Anders Hatlen made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Issue & fix info Patch Available [ 10102 ]
          Fix Version/s 10.9.0.0 [ 12316344 ]
          Resolution Fixed [ 1 ]
          Knut Anders Hatlen made changes -
          Issue & fix info Patch Available [ 10102 ]
          Knut Anders Hatlen made changes -
          Attachment d5539-2a.diff [ 12515584 ]
          Knut Anders Hatlen made changes -
          Link This issue incorporates DERBY-5550 [ DERBY-5550 ]
          Knut Anders Hatlen made changes -
          Attachment d5539-1b.diff [ 12508223 ]
          Knut Anders Hatlen made changes -
          Attachment d5539-1a.diff [ 12508074 ]
          Knut Anders Hatlen made changes -
          Field Original Value New Value
          Status Open [ 1 ] In Progress [ 3 ]
          Knut Anders Hatlen created issue -

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development