The Jenkins Password Parameter Obituary

Blaine Whited

17 October 2017

Jenkins Password Parameters, born on August 3, 2009, lived its life and provided useful functionality to many a time-pressed user. Its life was a storied one, as evident from the amount of bad decisions that were allowed to persist by using this function. Jenkins Password Parameters, is survived by Jenkins Credentials Parameters, which provides better security and ease of use. In lieu of flowers, a small donation should be directed to Jenkins’ donation page.


Authentication and authorization are not new concepts to many professionals who operate within the many facets of the software’s lifecycle. In addition, with automation being used to reduce as much of the mundane day-to-day operations as possible, being able to support the secure storage and use of sensitive strings is a very important. In the earlier days of automation, functionality provided by the Jenkins Password Parameter was a solid option for this need. It allowed Jenkins jobs to accept an encrypted string at execution-time, both by user input on the UI or via the API, or to use a pre-entered default. The Jenkins Credentials Parameter has reproduced this functionality and handily surpassed it in both security and ease of use.

In general, it’s best to avoid tools and procedures that require password based authentication when possible. (Exchanging pre-encrypted keys or using revocable tokens are just two examples of better options for security) If you must use secret text, then there is no reason to still be using Jenkins Passwords Parameters instead of Jenkins Credentials Parameters.

Increased Security

Jenkins Password Parameters are not inherently insecure, as evidenced in that any defaults or values used at runtime are stored on disk as an encrypted string.

Example build.xml that is produced by Jenkins after a run

But the problems with its security become more evident once you start to orchestrate the Jenkins jobs themselves. Any orchestration tool that lives on top of Jenkins instantly shows its security flaw when it needs to trigger a build using the Jenkins Password Parameter via the API.

A sample API usage of Jenkins Password Parameters showing that the password is sent via Plain-Text and not encrypted.

Since the only value stored on the system is the default (if used), to use a non-default value you must pass the parameter in plain text to the API as a urlencoded string.

This is a big problem if users are careless with the tools they choose for orchestration.

Specifically, the onus of keeping the password secure is placed on the orchestrating tool that sits above Jenkins.

As a side note, because secure transport mechanisms are a constantly moving target and because no one should rely on a single source of security I’m intentionally ignoring the increased security that comes with using secure transport mechanisms like TLS which provide server-to-server encryption.

The Jenkins Credentials Plugin solves this limitation by expecting the sensitive data to be pre-entered into Jenkins itself.

Encrypted string entered into Jenkins Credentials

This ensures that the credentials do not have to be shared to other systems where they may be insecurely used. Similarly, this also allows for changes and updates to these credentials to be easily managed as Jenkins uses a single credentialstore. This previously required a separate plugin to manage within a global password list. Additionally, if your organization requires password aging, as most larger organizations do, gone are the days of needing to update several jobs because some admin password somewhere changed. Simply update the credentials within the Credentials page in Jenkins, and all jobs using it will begin to use the updated value(s).

Orchestrating the use of credentials using the Jenkins API becomes safer as well with credentials. Instead of passing my sensitive data to Jenkins via the API, all that is needed is to select the credentials by it’s unique ID. (An example is shown above) The secret is then loaded into the job for use at run-time. Doing it this way means the sensitive data is no longer required to be stored outside of Jenkins itself.

A sample API usage of Jenkins Credentials Parameters showing that the sensitive data is merely selected and not transmitted.

Increased Usability

Jenkins Credentials support many distinct types as well, which allow for greater control. At the time of writing this article, the built-in credential types show just how much more useful it is to use credentials.

Dropdown within a fresh Jenkins installation’s new credentials page.

  • Usernames and passwords are married together, simplifying their use.
  • Native SSH key pairs, which was achievable with extra plugins before Jenkins Credentials, but less intuitive to be sure.
  • Secret text gives the Jenkins jobs some backwards compatibility with the features of old Jenkins Password Parameters.

Jenkins Password Parameters, while providing useful functionality in the earlier years of automating within Jenkins, has been completely replaced with a superior system both in terms of security and usability. It is still widely regarded as a best practice, when possible, to find other ways to handle authentication to external systems However, if you have no other options, Jenkins Credentials should be your system of choice.

I ask that you join me in honoring the death of the Jenkins Password Parameter.