microsoft-authentication-library-for-js: Docs should not recommend to developers to store secrets in code

Core Library

MSAL Node (@azure/msal-node)

Wrapper Library

Not Applicable

Public or Confidential Client?

Public, Confidential

Documentation Location

https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/ab44706bcf8e5a281b70ac93a44c58420c07d16a/lib/msal-node/docs/certificate-credentials.md?plain=1#L79

Description

“Secrets must not be present in code, documentation, telemetry or pipelines”

In certificate-credentials.md lines 69 - 97:

### Initializing MSAL Node with certificates
const msal = require('@azure/msal-node');
const config = {
    auth: {
        clientId: "YOUR_CLIENT_ID",
        authority: "https://login.microsoftonline.com/YOUR_TENANT_ID",
        clientCertificate: {
            thumbprint: "CERT_THUMBPRINT", // a 40-digit hexadecimal string
            privateKey: "CERT_PRIVATE_KEY", <==== BAD
        }
    }
};

// Create msal application object
const cca = new msal.ConfidentialClientApplication(config);

Both `thumbprint` and `privateKey` are expected to be strings. `privateKey` is further expected to be in the following form (*PKCS#8*):

-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIJQwIBADANBgkqhkiG9w0BAQEFAASCCS0wggkpAgEAAoICAQDkpKPrsfpIijS3
z2HCpDsa7dxOsKIrm7F1AtGBjyB0yVDjlh/FA7jT5sd2ypBh3FVsZGJudQsLRKfE
// ...
-----END ENCRYPTED PRIVATE KEY-----

This is very bad advice and against security policy. It is extremely common that a security breach results from developers putting secrets in the source code.

docs/certificate-credentials.md line 110 is problematic too:

 const privateKeySource = fs.readFileSync('./example.key')

The file path (starting with ‘./’ ) suggests that the file containing the secret is to be found in the current directory. I don’t know what the current directory is likely to be in practice, but it seems plausible that this suggestion will, again, lead to developers storing secrets within their source tree where it will get checked-in and leaked.

Some other apparent instances of this issue:

• https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/ab44706bcf8e5a281b70ac93a44c58420c07d16a/lib/msal-node/docs/certificate-credentials.md?plain=1#L216
• https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/ab44706bcf8e5a281b70ac93a44c58420c07d16a/lib/msal-node/docs/sni.md?plain=1#L36
• https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/ab44706bcf8e5a281b70ac93a44c58420c07d16a/samples/msal-browser-samples/HybridSample/bin/www#L38
• https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/ab44706bcf8e5a281b70ac93a44c58420c07d16a/samples/msal-node-samples/auth-code-with-certs/README.md?plain=1#L38
• https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/ab44706bcf8e5a281b70ac93a44c58420c07d16a/lib/msal-node/docs/key-vault-managed-identity.md?plain=1#L79
• https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/ab44706bcf8e5a281b70ac93a44c58420c07d16a/lib/msal-node/docs/initialize-confidential-client-application.md?plain=1#L27

A better practice that example code could show would be reading the secret/private key from a secret store API. If such an API is not available cross-platform, then reading the secret from an environment variable is the next best thing. (Remind developers to set the environment variable outside of anything in the source tree.)

Other resources:

• Microsoft Defender for Cloud - Detect exposed secrets in code
• Getting started with Credential Scanner (CredScan)
• Secure Application Lifecycle - Part 1 - Using CredScan
• What is the best practice to store secret keys/api keys in production?