Forem: T.O.

Stop Treating Credential Generation as an Auditor Scramble

T.O. — Tue, 14 Apr 2026 13:52:20 +0000

How to bake compliance evidence into the process before your next SOC2 or HIPAA audit.

The pattern shows up the same way every time. Audit prep starts and someone asks for proof that credentials were generated securely. Engineers scramble to pull Git history, check deployment logs, and screenshot password manager settings. They end up writing a three paragraph explanation of what they think their generation process does.

The auditor reviews it and says the evidence is insufficient.

Manual reconstruction always turns into pain. Not sometimes. Every time.

Why manual reconstruction fails auditors

Auditors are not asking whether you have a good process today. They are asking whether you had a documented, consistent, repeatable process at the time each credential was generated. Those are two completely different questions.

You can have an excellent process right now and still fail an audit because you cannot prove what was true six months ago. The entropy level, the compliance policy, the timestamp, the system that generated it. If that information was not captured at creation time it effectively does not exist. Retroactive reconstruction is not evidence. It is a story.

What baking evidence into the process actually means

The scalable answer is not better documentation or more screenshots. It is making evidence generation automatic and inseparable from the credential generation itself.

Every time a credential is created these five things should be captured automatically in the same operation:

The generation method. Not just the library name. The specific cryptographic function, the entropy source, and the parameters applied.

The compliance policy. Which standard was active at the moment of creation. NIST 800-63B, SOC2, HIPAA, or your internal standard.

The entropy bits. The mathematical proof of randomness. This is the specific number auditors increasingly demand and most teams cannot produce.

The timestamp. Exact ISO format with timezone. Not an approximation reconstructed from logs.

The environment and caller. Which system requested the credential and in which environment.

When these are captured automatically in every generation event you move from telling stories to providing compliance artifacts. The auditor asks for proof. You pull the log. Finding closed.

Here is what that structured log event looks like in practice:

{
  "event": "credential.generated",
  "generated_at": "2026-04-13T14:32:01.847Z",
  "compliance_profile": "SOC2",
  "entropy_bits": 116,
  "length": 20,
  "method": "crypto.randomInt",
  "environment": "production",
  "caller": "user-provisioning-service",
  "calls_remaining": 49847
}

Every field exists at creation time. Nothing reconstructed. Nothing approximated.

The written standard most teams skip

Before you can automate evidence you need a written standard. Most teams skip this because it feels like paperwork. It is not paperwork. It is the specification your automation implements.

Your standard should answer these questions in writing:

Minimum credential length per environment
Entropy threshold that constitutes compliance with your applicable standard
Which compliance profile applies to which system type
Log retention period and access controls
Who can query the audit log and under what conditions

Without written standards your automation is generating evidence for a policy that does not exist on paper. Auditors will note that gap separately.

The shift that changes everything

The teams that handle audits well are not necessarily the ones with the best security. They are the ones whose security controls speak auditor language automatically.

A credential generated with crypto.randomInt is objectively more secure than one generated with Math.random. But if neither produces a compliance artifact at creation time they look identical to an auditor. Zero evidence is zero evidence regardless of which function generated the credential.

The goal is not just generating secure credentials. The goal is generating secure credentials that prove their own integrity the moment they are created. That proof has to exist at creation time. Not when your auditor asks for it.

Why Math.random() Will Fail Your Next Security Audit

T.O. — Fri, 10 Apr 2026 16:38:41 +0000

If you have ever written something like this in a production codebase:

const secret = Math.random().toString(36).slice(2);

You have shipped a credential that will fail a security audit.
Not might fail. Will fail.
Here is why that matters and what to do about it before your auditors find it first.
With the renewed focus on Executive Order 14028 and software supply chain security, auditors are no longer just looking at what libraries you use. They are looking at how you use them to generate internal secrets. Credential generation is now explicitly in scope for supply chain security reviews in ways it was not three years ago.
The problem with Math.random()
Math.random() is not a cryptographic function. It was never designed to be. It generates pseudorandom numbers that are fast and statistically distributed enough for things like shuffling a playlist or generating a random color. It is completely wrong for generating secrets, API keys, passwords, or any credential that needs to be unpredictable to an adversary.
The specific problem is predictability. Math.random() uses a deterministic algorithm seeded by the JavaScript engine. In some environments that seed is observable or reconstructible. In all environments the output fails the entropy requirements defined in NIST 800-63B, the federal standard for digital identity and credential strength.
When an auditor runs entropy analysis on your generated credentials and finds Math.random() in the generation path, the finding looks like this:

AUDIT FINDING — CRITICAL
Control: SC-28 / NIST 800-53

Finding: Credential generation function Math.random()
identified across microservices.

Impact: Generated secrets fail entropy requirements
for NIST 800-63B compliance. Cryptographic randomness
cannot be verified.

Status: OPEN - 90 day remediation required

That finding stops deals, delays launches, and costs engineering time to remediate retroactively. The fix at that point is expensive because you have to find every place Math.random() was used, replace it, rotate the affected credentials, and produce documentation proving the new generation method is compliant.
The right function is already in Node.js
You do not need a library. You do not need a third party service. Node.js ships with a cryptographically secure random number generator in the built-in crypto module:

`const { randomInt, randomBytes } = require('crypto');

// Generate a random integer between 0 and charset.length
const index = randomInt(0, charset.length);

// Generate random bytes for a hex token
const token = randomBytes(32).toString('hex');`

crypto.randomInt() uses the operating system's cryptographically secure pseudorandom number generator. On Linux that is /dev/urandom. The output passes NIST entropy requirements because the source of randomness is designed for exactly this purpose.
The fix is a one line change in most cases. The problem is that most teams never make it because nobody flags it until an auditor does.
A copy-paste utility for your codebase

If you want a drop-in replacement you can put in your utils/ folder today, here is a minimal version using only Node.js built-ins:

`const { randomInt } = require('crypto');

const CHARSETS = {
uppercase: 'ABCDEFGHJKLMNPQRSTUVWXYZ',
lowercase: 'abcdefghjkmnpqrstuvwxyz',
numbers: '23456789',
symbols: '!@#$%^&*'
};

function generateSecureCredential(length = 20, options = {}) {
const {
uppercase = true,
lowercase = true,
numbers = true,
symbols = false
} = options;

let charset = '';
if (uppercase) charset += CHARSETS.uppercase;
if (lowercase) charset += CHARSETS.lowercase;
if (numbers) charset += CHARSETS.numbers;
if (symbols) charset += CHARSETS.symbols;

if (!charset) throw new Error('At least one character set required');

return Array.from(
{ length },
() => charset[randomInt(0, charset.length)]
).join('');
}

// Usage
const secret = generateSecureCredential(20, {
uppercase: true,
lowercase: true,
numbers: true,
symbols: true
});`

This gives you cryptographic security but not compliance documentation. For NIST 800-63B audit trails, entropy calculation, and machine-readable compliance metadata, that is what you need to add on top of this foundation.
The documentation gap nobody talks about
Switching from Math.random() to crypto.randomInt() is the technical fix. But it does not solve the audit problem completely.
Auditors do not just want secure credentials. They want documented proof that credentials are secure. That means:

Entropy bits calculated per credential
Generation method documented at the time of creation
Compliance profile recorded alongside the credential

Most internal credential generation systems do not produce this documentation automatically. Engineers have to build it separately, maintain it, and make sure it stays accurate as the codebase evolves. Most teams never complete that work.
This is the gap that causes audit findings even when the underlying generation is technically correct. You fixed Math.random() but you have no proof you fixed it that satisfies an auditor asking for evidence.
What shift-left credential security looks like
The concept of shifting security left means solving security problems at the earliest possible point in the development workflow, not after auditors find them.
For credential generation that means every credential that ships should come with documented proof of how it was generated, what entropy it has, and which compliance standard it meets. That documentation should be automatic, not something an engineer produces manually six months later when someone asks for it.
If you want to automate that documentation piece entirely, this is how we structured the Six Sense API to handle it:

`const response = await fetch('https://api.sixsensesolutions.net/v1/generate', {
method: 'POST',
headers: {
'Authorization': 'Bearer your_api_key',
'Content-Type': 'application/json'
},
body: JSON.stringify({
length: 20,
quantity: 1,
compliance: 'NIST',
options: {
uppercase: true,
lowercase: true,
numbers: true,
symbols: true,
exclude_ambiguous: true
}
})
});

const { passwords, meta } = await response.json();

console.log(meta);
// {
// length: 20,
// entropy_bits: 120.4, // <-- This is your audit evidence. 120+ bits exceeds NIST minimum.
// generated_at: "2026-04-10T14:57:35Z",
// compliance_profile: "NIST",
// calls_remaining: 49999
// }`

Every response includes entropy_bits and compliance_profile in the metadata. That metadata is the audit documentation. Your auditor asks for proof that credentials meet NIST 800-63B. You show them the response metadata. The finding closes.
The free tier
If you want to test this in your own codebase, there is a free tier at sixsensesolutions.net with 500 calls per month and no credit card required. Signup generates a real API key instantly.
The NIST and SOC2 compliance profiles enforce minimum lengths, character requirements, and ambiguous character exclusion automatically. The strong profile respects whatever options you pass directly.
The takeaway
If your codebase contains Math.random() in any credential generation path, you have a finding waiting to happen. The technical fix is one line and the copy-paste utility above gives you that today for free. The documentation fix is what most teams skip and what auditors actually ask for.
Both need to be in place before your next audit, not after.