Text & everyday tools · Password Generator
crypto.getRandomValues vs Math.random: why it matters for passwords
· How it works
passwords web-crypto randomness
Explains the difference between a browser's general-purpose random number generator and its cryptographic one, why predictability is fatal for passwords, and how to tell which a tool uses.
Random enough for a dice game, not for a password — the two kinds of randomness a browser offers
A browser can offer more than one source of values that look irregular, but visual disorder is not evidence that a sequence is suitable for a credential. ToolAcre draws a hard product boundary: every word choice, delimiter choice, character choice and shuffle swap passes through one secure integer function backed by `crypto.getRandomValues`. If that API cannot be used, the page disables generation rather than producing a plausible-looking substitute.
That refusal matters more than whether two sample outputs appear equally jumbled. A predictable source can still print letters, digits and words that look convincing to a person. The implementation therefore makes the source auditable and the failure visible. It does not claim that any generated value is safe for every environment; a compromised browser or device can still read what the page displays.
What Math.random is for — fast, seeded pseudo-randomness whose output can be reconstructed from a few observations
The workbook describes Math.random as seeded pseudo-randomness reconstructable from a few observations, but those are general implementation claims this repository does not establish for every JavaScript engine. The local fact is simpler and stronger for this product: production generator files do not call `Math.random`. A source-level test strips comments, scans executable code and fails if such a call appears anywhere in the engine or password app.
This distinction keeps the article from turning an implementation rule into a universal browser-history lecture. ToolAcre does not need to characterize every possible Math.random algorithm to reject the API for password generation. Its package accepts Web Crypto or an injected secure source used by tests, and exposes no production option for a seed, deterministic mode or weak fallback.
What this repository proves about Math.random: it is absent from production generation
`createWebCryptoSource` looks for a callable `getRandomValues`, then wraps that method as the package random source. The application performs an additional probe before enabling controls: it asks the global crypto object to fill a one-element typed array inside a try block. That catches restricted environments where the property exists but throws when used, rather than trusting a superficial feature check.
The source stops at the browser API boundary. It does not prove which operating-system pool, hardware instruction or reseeding design lies underneath a particular browser. Those details vary below the interface and need platform documentation. What the code does prove is that bytes arrive through the named Web Crypto method and that generation is not attempted when the probe fails.
What crypto.getRandomValues does here: fills typed arrays through the browser API
Predictability is dangerous because a credential generator is supposed to make fresh choices an observer cannot reproduce from earlier output. ToolAcre supports that goal by refusing deterministic production paths, centralising every draw and testing that the weak API is absent. It does not promise immunity from screen capture, extensions, malware, phishing, password reuse or a service that mishandles the credential after submission.
That boundary prevents a common category error: generation addresses how a candidate is selected, not everything that happens to it later. The package returns a string and does not log or store it. The page holds one current value in memory and renders it as text. Password storage, transmission, account recovery and authentication policy remain responsibilities of other systems.
Reading the code — how to check which API a page uses, and why open, inspectable pages are easier to trust
Reading the code starts at `packages/password-generator/src/index.js`, whose contract says every random decision reaches `secureRandomInt`. The implementation file then shows `getRandomValues`, rejection sampling and explicit errors. Finally, `no-math-random.test.js` and the broader password security suite make the negative guarantee executable instead of leaving “we never use Math.random” as an untested comment.
Open source alone does not make code correct, but it gives a reviewer concrete seams to inspect. Search for the random source, follow callers through choices and shuffles, and inspect what happens when the API is missing. A trustworthy review should be able to name both the success path and the refusal path rather than infer security from branding.
Worked example — the same word-picking routine written both ways, and what an attacker could do with each
Consider a request for an integer below 100. `secureRandomInt` needs one byte, whose range contains 256 values. It accepts only the largest prefix divisible by 100, which ends before 200, and rejects the remaining tail. A deterministic test feeds byte 200 followed by byte 7. The implementation discards 200 and returns 7; a direct modulo shortcut would have returned zero from the rejected byte.
The same secure integer function chooses indices for words and characters, so this example is not a toy detached from generation. The exact bytes in production are not repeatable examples and should never be published as a credential. The useful artifact is the control-flow proof: Web Crypto fills the buffer, an uneven tail is rejected, and only an accepted value becomes a bounded choice.
Worked example: trace one bounded draw through the shipped secureRandomInt path
This repository does not implement or compare server-side generators, hardware random number generators or operating-system command-line tools. It also cannot audit the internals of the browser crypto implementation from JavaScript. Those topics need their own source material, threat models and operational checks rather than an analogy pasted onto the ToolAcre code path.
The page also is not a password manager. It does not save, synchronise, transmit or autofill what it generates. A reader should not interpret “cryptographic random source” as advice to reuse a result or move it through an insecure channel. The claim belongs only to selection inside the current browser tab.
The takeaway — the Password Generator uses the browser's cryptographic random number generator, and you can verify it from the page itself
ToolAcre’s verifiable choice is crypto or nothing. The page calls the browser API during support detection, disables controls when it fails, and lets the engine throw `InsecureRandomError` if generation somehow reaches the same missing condition. There is no Math.random fallback hidden behind either branch.
Use that pattern when reviewing a generator: identify the source, trace every bounded draw, inspect reduction and shuffling, and force the unavailable-source path. Then evaluate the device and destination separately. A sound random source is necessary for this generator’s job, but it is not a universal certificate for the credential’s entire life.