Mitigating leaked personal access tokens (PATs) found on GitHub public repositories

Parsa

Personal access tokens (PATs) make it easy to integrate your tools with Azure DevOps or extend Azure DevOps functionality for your business needs. However, like other authentication credentials, personal access tokens need to be stored securely. Leaked tokens could compromise your Azure DevOps account and data, putting your applications and services at significant risk.

One all too common threat is accidentally checking your personal access tokens into your repositories.

GitHub is the home for all developers on the planet to host their projects, contribute to open source and leverage the power of the community to achieve their goals faster. However this means that secure credentials like personal access tokens checked into public repositories on GitHub are susceptible to even more risk, particularly since malicious actors are always scanning these public repositories for opportunities.

I am excited to announce that the Azure DevOps security team, in collaboration with our partners at GitHub, will begin to scan for Azure DevOps personal access tokens (PATs) checked into public repositories on GitHub. When our team discovers a leaked token, we’ll immediately send a detailed email notification to the token owner and log an event to your Azure DevOps Organization’s Audit Log. We encourage impacted user(s) to mitigate immediately by rotating or revoking the leaked token. If the token has not been rotated or revoked after 72 hours, we will automatically revoke the token on your behalf. You will receive another email notification and audit log event once the token has been revoked.

Please comment below if you have any questions or concerns!

9 comments

Comments are closed. Login to edit/delete your existing comments

  • Jesse Houwing

    Great feature to add! Any chance we could opt in for immediate revocation?! A lot of harm can be done in 72h, especially when a token has all orgs/all access permissions. And in my experience most people pick that to not have to figure out exactly what permissions they need…

    • pazandMicrosoft employee

      Thanks for the comment! For now there isn’t an opt-in for immediate revocation. However, this is clearly something some customers will want. We wanted to start with 72 hours to give people a heads up before we break any essential production tools and services.

      This will be of interest to you: we’ll be posting an update to our Feature Timeline over the next few days. We’re working on some global policies that admins can use to prevent the creation of global/full-scoped PATs and reduce the risk of any given leaked PAT.

      • fj

        To reiterate @jesse comment, this is great news!

        May I suggest that alongside any revocation feature, Github provides a facility to easily destroy the file and it’s associated history. It’s not just tokens that can be included in a commit by accident! 🙂

  • Maciej Porebski

    It would be great to see this extended to Azure Repos in the future, ideally even adding ability to block tokens from being pushed to repos 🙂

  • Steve Hansen

    Does this work at the commit level or just the latest source? Like when a commit would have a token, and then another commit to remove it, but it would still be leaked in the history of that repository.

  • Paul Williams

    Newbe:

    That is extremely good news for security. However, I am now unsure now how to publish nuget packages, without leaking token/key/whatever, if my nuget.config cannot contain the token/key.

    All examples / tutorials I have seen say to include (in nuget.config) an entry such as:

    add key="ClearTextPassword" value="ghp_KEY"

    For example: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-nuget-registry

    If I follow these examples, then GitHub will revoke my token as soon as I check-in my code.

    In fact, I had a private repo that was working fine, but as soon as I made it public my token was revokened as it was contained within the nuget.config file.

    Some basic instructions would help here, or links to further information, would be greatly appreciated.

    Many thanks.