Submitting as delegate for a Cisco pen-testing team
      This is an enhancement to improve the security posture of the default Jenkins install.

      Headline: Disable Jenkins API tokens by default
      Platforms: Jenkins
      Versions: 1.622
      CWE Tags: CWE-671, CWE-424

      Jenkins allows users to authenticate via multiple mechanisms, including an
      automatically generated API token. Despite the name, the API token provides
      users with a fully authenticated session (the same as if the user had logged in
      using a password).

      In many common usage scenarios, a user may never require an API token. For
      example, a user who exclusively accesses Jenkins via the web-based UI will never
      use an API token. Although probably less common, a user who exclusively
      utilizes the SSH-based Jenkins CLI will also never use an API token.

      In scenarios such as these, the existence of an active API token serves no
      purpose to the user and represents a weakness in that it broadens the overall
      attack surface. For this reason, API tokens should not be generated for users
      unless they explicitly request a token. Furthermore, individual users should
      have the ability to remove/disable existing API tokens. Lastly, Jenkins
      administrators should be able to remove a user's API token (e.g. if the token
      has been compromised) and disable the usage of API tokens system-wide.

      References:
      http://cwe.mitre.org/data/definitions/424.html
      http://cwe.mitre.org/data/definitions/671.html

          [JENKINS-32442] Disable Jenkins API tokens by default

          Daniel Beck added a comment -

          This is a good suggestion. Thank you.

          While security related, this is not a vulnerability, so I'll move it to the public JENKINS tracker unless someone objects.

          Daniel Beck added a comment - This is a good suggestion. Thank you. While security related, this is not a vulnerability, so I'll move it to the public JENKINS tracker unless someone objects.

          Moving to public is fine by me.

          Craig Lorentzen added a comment - Moving to public is fine by me.

          Jesse Glick added a comment -

          Jenkins administrators should be able to remove a user's API token (e.g. if the token has been compromised)

          This at least is already possible—at least, you can force it to be updated to a new random value.

          I suspect the whole token system could be moved into a plugin, which paranoid administrators could simply uninstall. TBD if the core API for registering a custom servlet filter is sufficiently powerful for this case.

          Jesse Glick added a comment - Jenkins administrators should be able to remove a user's API token (e.g. if the token has been compromised) This at least is already possible—at least, you can force it to be updated to a new random value. I suspect the whole token system could be moved into a plugin, which paranoid administrators could simply uninstall. TBD if the core API for registering a custom servlet filter is sufficiently powerful for this case.

          Oleg Nenashev added a comment -

          +1 for moving.
          It's a good proposal for security hardening

          Oleg Nenashev added a comment - +1 for moving. It's a good proposal for security hardening

          Jesse Glick added a comment -

          It would be handy to have a method in JenkinsRule.WebClient to logInViaApiToken(String username) which could be used for testing permission checks on API requests. (Plenty of tests already use login(String) for this purpose but it is slow as it needs to open the login HTML page and submit the form, when we could simply addRequestHeader to use token authentication without any actual login request.) However such a test utility would be broken by turning off tokens by default (or moving them to an optional plugin) unless some care was taken to ensure that Java-level calls to User.get(…).getProperty(ApiTokenProperty.class).getApiToken() continued to generate a token on demand.

          Jesse Glick added a comment - It would be handy to have a method in JenkinsRule.WebClient to logInViaApiToken(String username) which could be used for testing permission checks on API requests. (Plenty of tests already use login(String) for this purpose but it is slow as it needs to open the login HTML page and submit the form, when we could simply addRequestHeader  to use token authentication without any actual login request.) However such a test utility would be broken by turning off tokens by default (or moving them to an optional plugin) unless some care was taken to ensure that Java-level calls to User.get(…).getProperty(ApiTokenProperty.class).getApiToken() continued to generate a token on demand.

          Correction released in 2.129.

          Wadeck Follonier added a comment - Correction released in 2.129.

            wfollonier Wadeck Follonier
            crlorent Craig Lorentzen
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: