Mitigating leaked personal access tokens (PATs) found on GitHub public repositories
pazand
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, log an event to your Azure DevOps Organization’s Audit Log and revoke the token on your behalf.
Please comment below if you have any questions or concerns!
Light
Dark
10 comments
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…
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.
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! 🙂
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 🙂
Yes please!
Thanks for the feedback! This is definitely something we want to do! Check our Feature Timeline for any public commitments.
Thanks a lot for sharing. Really amazing blog. I learnt a lot
Best Regards
Sachin Patil
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.
This works on commit.
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:
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.