Maven
  1. Maven
  2. MNG-4626

Password encryption escaped mechanism doesn't work as advertised

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 3.0-alpha-7
    • Fix Version/s: None
    • Component/s: General
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      The current encryption scheme implemented by Maven avoids the use of cleartext passwords on local files by allowing them to be encrypted locally and decrypted just before the maven client requests from or deploys to a central artifact repository.

      I would like to suggest that the Maven team replicate the idea adopted by Artifactory, where passwords are transmitted encrypted, and only decrypted on the server side by the repository. Requests and deployments are made over http and transmitted in the clear. Where the passwords are system passwords integrated to Active Directory or similar using LDAP, this is not an option even within a company's LAN. I like the idea of where Nexus and the Maven development stack in general is going (I listened to Jason's seminar recently and I'm keen on much of where you are going). But passwords in the clear over http is a showstopper and I'm surprised you haven't already borrowed this idea from the competition.

      Another irritating side effect of maven's insistence in using cleartext passwords has been mentioned by a colleague of mine in MNG-4611. We currently use Artifactory for EXACTLY this reason (the password encryption) and maven logs loudly about the fact that the passwords are encrypted.

        Issue Links

          Activity

          Hide
          brianfox brianfox added a comment -

          Maven was built assuming no intelligence on the repository side, so it exactly follows the http standards wrt authentication. Simply encrypting the password is a false sense of security, if you really have sensitive data, you should instead be using https to encrypt the whole transfer. The encryption built into Maven 2.1 was intended to provide a way to give some security to your password by obscuring it from the settings.xml. Naturally to conform to http standards, we needed to reverse the encryption before putting in on the wire.

          There may be some consideration done to define a new repository manager protocol and some password encryption around that, but for the moment, this seems to be out of scope for Maven itself.

          That said, we have developed this functionality in Nexus Pro, but never shipped it because of some incompatibilities with the sun http provider in some edge cases. It sort of fell off the priority list, but we will be resurrecting and polishing this up soon.

          Show
          brianfox brianfox added a comment - Maven was built assuming no intelligence on the repository side, so it exactly follows the http standards wrt authentication. Simply encrypting the password is a false sense of security, if you really have sensitive data, you should instead be using https to encrypt the whole transfer. The encryption built into Maven 2.1 was intended to provide a way to give some security to your password by obscuring it from the settings.xml. Naturally to conform to http standards, we needed to reverse the encryption before putting in on the wire. There may be some consideration done to define a new repository manager protocol and some password encryption around that, but for the moment, this seems to be out of scope for Maven itself. That said, we have developed this functionality in Nexus Pro, but never shipped it because of some incompatibilities with the sun http provider in some edge cases. It sort of fell off the priority list, but we will be resurrecting and polishing this up soon.
          Hide
          Paul Benedict added a comment -

          Even with an encrypted password sent over HTTP, unless the encryption is time sensitive (nonce?), an intercept could allow its unauthorized reuse.

          Show
          Paul Benedict added a comment - Even with an encrypted password sent over HTTP, unless the encryption is time sensitive (nonce?), an intercept could allow its unauthorized reuse.
          Hide
          Brett Porter added a comment - - edited

          can I sum up, between the two issues, that you want Maven to not decrypt the password in settings.xml, and that Artifactory is using the same algorithm and master key ? So a suitable escaping mechanism (that works as documented on the page) would be sufficient? That should be fine to do, but I otherwise agree using https for your repository is a better option all around.

          Show
          Brett Porter added a comment - - edited can I sum up, between the two issues, that you want Maven to not decrypt the password in settings.xml, and that Artifactory is using the same algorithm and master key ? So a suitable escaping mechanism (that works as documented on the page) would be sufficient? That should be fine to do, but I otherwise agree using https for your repository is a better option all around.
          Hide
          Brendan Lawlor added a comment -

          Brian: Point taken on using https. It just seems like a lot of encryption for a little password, but as Paul points out, just a statically encrypted password can still be reused (though only in the context of the Artifactory/Nexus server).

          Brett: that sums up things pretty well. I'll look into switching over to https and see if there is a big performance penalty (potentially nasty for our very busy continuous integration engine). In the meantime, it would be very nice if the escaping mechanism did what it says on the box (perhaps a separate JIRA for that one?)

          Many thanks for the replies.

          Show
          Brendan Lawlor added a comment - Brian: Point taken on using https. It just seems like a lot of encryption for a little password, but as Paul points out, just a statically encrypted password can still be reused (though only in the context of the Artifactory/Nexus server). Brett: that sums up things pretty well. I'll look into switching over to https and see if there is a big performance penalty (potentially nasty for our very busy continuous integration engine). In the meantime, it would be very nice if the escaping mechanism did what it says on the box (perhaps a separate JIRA for that one?) Many thanks for the replies.
          Hide
          Brett Porter added a comment -

          changed the summary accordingly. I haven't had the chance to test it yet.

          Show
          Brett Porter added a comment - changed the summary accordingly. I haven't had the chance to test it yet.
          Show
          Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
          Hide
          Jason van Zyl added a comment -

          Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          Show
          Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

            People

            • Assignee:
              Unassigned
              Reporter:
              Brendan Lawlor
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: