In April 2021, GitHub announced changes to their security token format that significantly enhanced security. The improvement leveraged two straightforward techniques: a fixed signature in the generated token and a checksum – both of which are highly effective in eliminating false positives (noise) and false negatives (missed findings).

Microsoft also implements these techniques widely in our service providers. Internally, we refer to any key format that incorporates both techniques as ‘identifiable’ (a term also used in GitHub’s blog post). Identifiable secrets super-power open-source scan tools and more sophisticated systems (such as GitHub Advanced Security for Azure DevOps), improving the security posture of engineering teams without compromising engineer productivity. Within Microsoft, for example, we hard-block any identifiable keys from being persisted to source code, work items, etc. Because there’s no real chance of a false positive, we can be confident we haven’t wasted anyone’s time.

As Microsoft has applied these techniques, we’ve designed improvements to further enhance detection and response. One technique is to specify a fixed signature that signals conformance to a common key format standard (distinct from the signature that identifies the service provider that minted the key). This simple idea allows scanners to author a single detection to find any key conforming to our format. Scan tools may be updated over time to further classify a secret once discovered, but doing so isn’t required.

By implementing a shared standard for all of our key formats, Microsoft minimizes costs for scanners to secure our full ecosystem of service providers. Any other service provider, of course, is free to opt into these security features by also implementing the core format.

To encourage adoption, Microsoft will release a detailed technical document for the Common Annotated Security Standard (CASK) as open source. This standard defines a core set of requirements for minted keys. It also reserves space for platforms/service providers to encode their own metadata into minted tokens. (Microsoft has defined its own Azure-specific use of these reserved bits).

Essential elements of the platform-agnostic (‘common’) security features include the following.

Free of Special Characters

A CASK key consists solely of alphanumeric characters (i.e., the BASE62 alphabet). This allows a key to be transmitted in all contexts without any escaping or encoding.

Strong Entropy

CASK keys contain 52 encoded characters of randomized data, each of which provide log(62)/log(2) of entropy. Every generated key therefore has ~310 bits of entropy; strong enough (and then some) to prevent brute-forcing, even in a post-quantum world.

Fixed Signatures

CASK keys incorporate fixed signatures for the CASK standard itself and for the specific service provider that minted the secret. The core signature for CASK is JQQJ, a pattern that Microsoft has empirically observed is rare in source code (both public OSS and Microsoft’s own internal code). It is possible to implement accurate and extremely high-performance detection strictly by looking for this signature. Service providers additionally provide their own signature that further classifies the minted secret. Azure DevOps, for example, reserves the signature AZDO for its allocations.

Other Features

The CASK standard includes other useful features as well:

• Creation timestamps. Every CASK key includes a timestamp of its creation data (month and year). This information has utility in security response and enables enforcement of rotation policies.
• Dedicated test keys. CASK specifies a set of reserved test keys that allow tool developers and users to explore product functionality and ensure security controls are working – without putting valid secrets into the clear.

Microsoft encodes other useful metadata for Azure security keys in the platform-reserved component of its CASK keys. We will share more details on this soon.

We encourage service providers to review this standard and to consider implementing the format. We also welcome comments and suggestions to improve the standard (which can be versioned).