Add identifiable prefixes to API tokens

[daniel-beck]

Identifiable prefixes makes it easier to identify poor secret handling. See e.g. https://github.blog/engineering/platform-security/behind-githubs-new-authentication-token-formats/ for an (outdated at this point) description of benefits.

To really have users benefit from this, we can't allow the prefixes to be configurable though. WDYT?

Additionally, does it make sense to require prefixes by default already, or should that be done at a later point?

---

WIP, no real test coverage yet.

Testing done

Proposed changelog entries

• human-readable text

Proposed changelog category

/label

Proposed upgrade guidelines

N/A

Submitter checklist

• The Jira issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[timja]

I think token prefix should probably be configurable for OEM, e.g. cloudbees CI. but no UI and there should be warnings about don't do this unless you know what you are doing?

[timja]

this seems very long.

Have you done research into what other vendors use?

e.g. GitHub:

• ghp for GitHub personal access tokens
• gho for OAuth access tokens
• ghu for GitHub user-to-server tokens
• ghs for GitHub server-to-server tokens
• ghr for refresh tokens
  https://github.blog/engineering/platform-security/behind-githubs-new-authentication-token-formats/

[daniel-beck]

e.g. GitHub

Have you checked what their new tokens look like recently? 😉 Their prefix is now github_pat_ instead of ghp.

I considered the prefix jio_ (for jenkins.io) for a while, then I saw GH made much longer token prefixes, so I thought why not. jio in isolation is not identifiable as a Jenkins API token. Neither might jenkins_ alone.

[jglick]

Maybe OT but we could rename the Jenkins feature in GUI and docs to personal access tokens for consistency with GH and to emphasize that these are bound to a “user” (regular principal). Thus, jenkins_pat_.

[daniel-beck]

I think token prefix should probably be configurable for OEM, e.g. cloudbees CI. but no UI and there should be warnings about don't do this unless you know what you are doing?

I considered this, even had it in the code as a Java system property. The reason I removed it again is that I thought this could cause is that I do not really want prefixes to be optional besides a transitional period after introduction (the flag that currently exists).

With a user-configurable prefix, we end up with these options:

• Allow any prefix on validation, e.g., only look at the token after the last _. So _abcdef1234567890 and wtf_abcdef1234567890 are OK, just like jenkins_apitoken_abcdef1234567890.
• Basically soft revoke all API tokens if you restart Jenkins with a new prefix (until all secrets are updated with the new prefix).
• Make it fairly complex to configure (the prefix to emit, and a list of prefixes to accept for "legacy" support)

I liked none of them a lot.

In terms of the OEM argument, I'll definitely check with colleagues what the situation with CloudBees CI should be before I finalize this PR. There may be a middle ground, like a resource file in src/filter, from which to get the prefix.

[jglick]

This will prevent people from upgrading unless I misunderstand?

IMO:

• There is no need for a system property.
• All new tokens should start with the new prefix.
• Any existing tokens should still be honored (until regenerated).

[github-actions]

Please take a moment and address the merge conflicts of your pull request. Thanks!