At GitHub, we’re constantly striving to secure the supply chain with our products and features. Earlier this year, we announced a new authentication token format for GitHub, and we’re excited to share that npm access tokens will now follow the same format of GitHub authentication tokens.
Previously, the npm access tokens were created as a UUID pattern of 36 characters. This has its limitations, such as inaccurate detection of compromised npm tokens in packages and GitHub repositories.
Identifiable prefixes and higher entropy patterns
With the new pattern, access tokens now start with an identifiable prefix: npm so it is easier to be indexed by features like GitHub secret scanning and npm’s internal secret scanners to provide higher security for your packages. Moreover, the delimiter following after is no longer a - but an underscore _ which means that the full token can be selected when double-clicked (saving you 0.005 seconds 🎉 ).
Entropy is the logarithmic measure for information predictability. In the case of an access token, the higher the entropy, the better. By matching GitHub’s token format, our tokens are longer and have a larger alphabet. Because of this, we increased our entropy from 128 to 178!
The last six characters of the tokens consist of CRC32 checksum, which is encoded in our Base62 implementation to further eliminate false positives when scanning for leaked tokens.
Read more about the new format here.
What this means for you
We strongly encourage you to make the move toward the new format by resetting your existing access tokens. These improvements will help you mitigate any risk to compromised tokens as well as make our secret scanning detection more precise.
You can reset your personal access tokens by clicking on Access tokens under your npm Profile, deleting all of your old tokens, and creating new ones.
Thank you for helping us make npm more secure. ❤️
Tags:
Related posts
Execute commands by sending JSON? Learn how unsafe deserialization vulnerabilities work in Ruby projects
Can an attacker execute arbitrary commands on a remote server just by sending JSON? Yes, if the running code contains unsafe deserialization vulnerabilities. But how is that possible? In this blog post, we’ll describe how unsafe deserialization vulnerabilities work and how you can detect them in Ruby projects.
10 years of the GitHub Security Bug Bounty Program
Let’s take a look at 10 key moments from the first decade of the GitHub Security Bug Bounty program.
Where does your software (really) come from?
GitHub is working with the OSS community to bring new supply chain security capabilities to the platform.