Securing Repository Credentials with Nexus Pro User Tokens

August 8, 2012 By Tim O'Brien

Until yesterday I had a Maven Settings file in ~/.m2/settings.xml that contained following XML:


Silly, right? The only way to authenticate against Nexus was to drop my plaintext username and password in my Settings file, for anyone who gained access to my laptop to see. I’ve never been too happy with this approach, and even built-in support for encryption in Maven didn’t seem like much of an improvement over a plaintext password. The Maven-specific approach to password encryption still has to decrypt the password on the client, and if someone is using password encryption in Maven Settings file all you need to do to intercept the password is fire up Wireshark and read what Maven sends over the wire. (Maven’s built-in password encryption isn’t security at all, it’s security theater.)

Nexus Professional 2.1 takes a different approach, an approach that keeps the password encrypted in transit and which shifts the responsibility to the repository manager.

With Nexus Professional 2.1 we’ve taken one step further toward a more secure approach to distributing credentials – User Tokens. You can think of a User Token as you would an SSH key or sorts. When you configure your Maven Settings, you’ll need to supply some credentials (preferably not your plaintext username and password). With Nexus Professional, all you need to do is:

  1. Login into Nexus with your user credentials.
  2. Open up your profile.
  3. Select User Token from the profile settings dropdown.
  4. Press Access User Token

At this point, Nexus Professional will ask you for your username and password again just to make certain that you are who you say you are, and it will present you with a User Token that looks like this:


But, wait, how is this more secure? First, an attacker could still grab your user token and deploy to Nexus, but the damage would be limited to deployment and download. User Tokens are more secure because they are limited, you won’t use a User Token to login to the UI and make changes to Nexus, and, if your User Tokens happed to be compromised, you can reset them. Lastly, your plaintext password is never transferred over the wire.

What this change is doing is moving Nexus toward an authentication system on par with the security of a system that relies on public SSH keys (a system such as Github). This is just the first step toward making Nexus authentication more secure, and it’s a big step. If you find this feature useful, please let us know, and we hopeyou enjoy Nexus Professional 2.1. Download it today.

  • Michael-O

    Instead of introducing silly token support, a comprehensive SPNEGO/Kerberos all over the place would be much wiser.

    • Martin Todorov

      I agree. While this is all quite neat, a lot of organizations are stuck with using NTLM and Kerberos.

  • William Hovingh

    We’re not seeing the nexus:usertoken:current privilege showing up for our users in the Developer role. As an Administrator, I was able to get and use my User Token, but my Developers aren’t seeing that option.

  • Jason

    Seems like a nice feature and that it might help solve one of the small headaches we have – users AD passwords getting locked out when their password changes and they forget to change the settings.xml

    So along that vein: Does a token ever expire?
    For example does the token need to be updated in the settings.xml anytime that user’s nexus password (or AD password ) changes?

    • Michael-O

      Still pointless. We need SPNEGO support. This would be a tremendous improvement.

  • Manfred Moser

    @d458b7b6c6a64aafae2b5409a27ec1cb:disqus the token has to be regenerated whenever you change the AD password. Each user can do that reset in the UI themselves. Then they can access the new tokens there and cut and past the settings.xml section for server with the token into their file or use the settings download feature of the nexus maven plugin to get a new updates settings.xml.

  • Jason

    A follow up the token expiry question. Can an expired token lock an AD account? One of the issues that comes up is we force password changes regularly on AD and a common enough issue that occurs is forgetting to update the password in the .m2/settings.xml which quickly locks the AD account.