Jetty
  1. Jetty
  2. JETTY-1272

Provide the possibility to add a salt when calculating and verifiying the MD5 hash of a password

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 6.1.24
    • Fix Version/s: None
    • Component/s: Security and SSL
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Class org.mortbay.jetty.security.Credential provides the possibility to verify against a stored MD5 hash as well as providing one from a password given. Plain password hashes are vulnerable to rainbow table attacks when the password file is leaking (which could be the case when using HashUserRealm, which stores the hashes in a plain file). Therefore a salt is added to each password before being hashed to avoid this kind of attack. It would be worthwile to consider adding such a functionality to org.mortbay.jetty.security.Credential and org.mortbay.jetty.security.Credential.MD5.

      I am relating to version 6.1.24 I am currently using. I scanned the bug database not finding the issue, therefore I assume that it is present in all versions.

      Regards
      Richard

        Activity

        Michael Gorovoy made changes -
        Field Original Value New Value
        Assignee Greg Wilkins [ gregw ]
        Hide
        Greg Wilkins added a comment -

        Richard,

        Does the salt need to be protected? Would it be sufficient to have a setSalt method on the realm and related credential methods?

        If the configuration file that contains the salt is compromised at the same time as the stored MD5 hashes, is there any additional protection?

        Sorry if this is a dumb question, but I don't want to appear to be adding extra security unless I get it 100% correct.

        Show
        Greg Wilkins added a comment - Richard, Does the salt need to be protected? Would it be sufficient to have a setSalt method on the realm and related credential methods? If the configuration file that contains the salt is compromised at the same time as the stored MD5 hashes, is there any additional protection? Sorry if this is a dumb question, but I don't want to appear to be adding extra security unless I get it 100% correct.
        Hide
        Richard Birenheide added a comment - - edited

        Greg,

        please refer to http://en.wikipedia.org/wiki/Salting_(cryptography), I am afraid that I cannot account as deep expert, to be honest.

        Anyways, from my knowledge,the salt should not be per realm but rather per user. Therefore as a first step I would recommend the possibility to add a salt provider to the realm. Whenever the hash is calculated the salt provider is asked for the salt (returning a byte array), with the user name as parameter. Implementations would than have the possibility to inject the salt stored along with the user. The default implementation may store the user specific salt along with the hashed password, making the leaked hashes more secure against rainbow table attacks http://en.wikipedia.org/wiki/Rainbow_tables. Even though the salt is leaked with the hash in that case, it requires computing a rainbow table for each user which then is effectively the same as a brute force attack (rainbow tables for plain passwords can be downloaded from the internet), making the attack infeasible for strong passwords.

        While we are at it : MD5 has severe vulnerabilities, see http://en.wikipedia.org/wiki/MD5#Security, you might consider offering AES support as well or open up the Credential class in a way that a client may choose his favourite hashing algorithm (this would also enable support for the currently planned successor of AES). But this may be worth a separate bug report.

        Regards
        Richard

        Edit: Also a great read on the topic: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

        Show
        Richard Birenheide added a comment - - edited Greg, please refer to http://en.wikipedia.org/wiki/Salting_(cryptography) , I am afraid that I cannot account as deep expert, to be honest. Anyways, from my knowledge,the salt should not be per realm but rather per user. Therefore as a first step I would recommend the possibility to add a salt provider to the realm. Whenever the hash is calculated the salt provider is asked for the salt (returning a byte array), with the user name as parameter. Implementations would than have the possibility to inject the salt stored along with the user. The default implementation may store the user specific salt along with the hashed password, making the leaked hashes more secure against rainbow table attacks http://en.wikipedia.org/wiki/Rainbow_tables . Even though the salt is leaked with the hash in that case, it requires computing a rainbow table for each user which then is effectively the same as a brute force attack (rainbow tables for plain passwords can be downloaded from the internet), making the attack infeasible for strong passwords. While we are at it : MD5 has severe vulnerabilities, see http://en.wikipedia.org/wiki/MD5#Security , you might consider offering AES support as well or open up the Credential class in a way that a client may choose his favourite hashing algorithm (this would also enable support for the currently planned successor of AES). But this may be worth a separate bug report. Regards Richard Edit: Also a great read on the topic: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html
        Hide
        Greg Wilkins added a comment -

        Jesse,

        can you take this to best of breed status.

        Show
        Greg Wilkins added a comment - Jesse, can you take this to best of breed status.
        Greg Wilkins made changes -
        Assignee Greg Wilkins [ gregw ] Jesse McConnell [ jesse ]
        Hide
        Greg Wilkins added a comment -

        Richard,
        thanks for the information and pointers.

        Show
        Greg Wilkins added a comment - Richard, thanks for the information and pointers.
        Hide
        Jari Timonen added a comment -

        Salt is a must with hashed password. Otherwise MD5 passwords are extremely insecure. Current functionality is unusable. (JDBCLoginModule is also unusable)

        Please?

        Show
        Jari Timonen added a comment - Salt is a must with hashed password. Otherwise MD5 passwords are extremely insecure. Current functionality is unusable. (JDBCLoginModule is also unusable) Please?

          People

          • Assignee:
            Jesse McConnell
            Reporter:
            Richard Birenheide
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: