Complexity rules measure the wrong thing
Nearly every site asks for a capital, a digit and a symbol. It is close to useless, and the reason is that people satisfy rules in the cheapest available way.
Asked for a capital, they capitalise the first letter. Asked for a digit, they
append 1. Asked for a symbol, they append !. The result is Password1!, which
satisfies every rule and is in the first few thousand guesses of any real attack.
The rule constrains the shape of the password. An attacker is not guessing shapes; they are guessing likely strings, and rules that everyone satisfies the same way make the likely strings easier to enumerate.
Before you read on
Which is harder to guess: sixteen random lowercase letters, or eight random characters using the full printable set?
The sixteen lowercase letters, by a wide margin — about 75 bits of entropy against 52. Length multiplies the exponent while the alphabet only raises the base, so adding characters beats adding character types every time. This is exactly why composition rules produce weak passwords and why current guidance leads with length instead.
Entropy is the thing that resists guessing
The useful measure is how many equally likely results the process could have produced.
entropy in bits = length x log2(size of the alphabet)
8 characters, lowercase only = 8 x 4.7 = 37.6 bits
8 characters, all 94 printable = 8 x 6.55 = 52.4 bits
16 characters, lowercase only = 16 x 4.7 = 75.2 bits
4 words from a 7,776-word list = 4 x 12.9 = 51.7 bits
5 words from a 7,776-word list = 5 x 12.9 = 64.6 bits
Two things fall out of that table, and both are counterintuitive.
Length beats alphabet. Sixteen lowercase characters are far stronger than eight mixed ones, because length multiplies the exponent while the alphabet only raises the base.
A memorable phrase can match a random string. Four random words are about as strong as eight random printable characters, and enormously easier to type on a phone.
The condition that makes any of it true
Every number above assumes the choice was random. Not “arbitrary”, not “something I would not have thought of” — random, from a process without preference.
A phrase you chose yourself has almost none of that entropy, because you did not pick uniformly from 7,776 words; you picked from the few hundred that came to mind, in an order that made sense. A quoted lyric or a film title has essentially none.
This is also where implementations go wrong invisibly. Math.random is a fast
pseudorandom generator, seeded and predictable, and it produces output that looks
exactly as random as the real thing. The browser’s crypto.getRandomValues is
the one to use, and the tools here do — but nothing about the resulting string
would tell you which was used, which is why it has to be a rule rather than a
judgement made per case.
There is a second, subtler trap in the same area: taking a random number modulo the alphabet size skews the distribution towards the earlier characters whenever the alphabet does not divide evenly into the range. It costs a little entropy for free, and the fix is to discard and redraw rather than to fold.
A random identifier is not automatically a secret
A version 4 UUID and a generated password may draw bytes from the same browser cryptographic source, but their contracts are different. UUIDv4 spends six of its 128 bits on a recognisable version and variant layout and uses the remaining 122 to let independent systems choose identifiers with negligible collision risk. Its job is avoiding coordination, not proving that a caller is allowed to act.
An authentication secret has a threat model around guessing, disclosure, storage, revocation and comparison. RFC 9562 explicitly warns that UUIDs should not be assumed hard to guess and that mere possession should not grant access. So use a UUID as a database or message identifier and use a dedicated random token or password as the credential. Random-looking text is not a security property without the right surrounding protocol.
What current guidance actually says
NIST’s digital identity guidelines moved away from composition rules some years ago, and the shape of the advice is now:
- Length is the primary factor. Allow long passwords, and do not truncate.
- Check against known-breached lists rather than enforcing character classes.
- Do not force scheduled rotation. It makes passwords worse, not better, because people increment a number. Change on evidence of compromise.
- Allow paste, and allow every printable character. Blocking either fights password managers, which are the single most effective thing a person can do.
Most sites still enforce the old rules. The practical answer is a password manager plus a generator: unique per site, long, and never typed from memory — at which point how memorable it is stops mattering at all.
Common questions
Are complexity rules useless?
Not useless, but they measure the wrong thing and they backfire. Requiring a capital, a digit and a symbol produces "Password1!" far more often than it produces anything unguessable, because people satisfy the rule in the cheapest way. Length plus genuine randomness gets you far more resistance for far less user pain, which is why current guidance leads with those.
Is a passphrase really as strong as a random string?
It can be, if the words are chosen randomly from a large list and there are enough of them. Four words drawn at random from a list of 7,776 gives about 51 bits; five gives 64. What breaks it is choosing the words yourself — a phrase you thought of is not random, and quoting a song lyric is worse than a short random string.
Does changing passwords every 90 days help?
Current guidance says no, and recommends against forcing it. Scheduled rotation makes people pick weaker passwords and change them predictably — appending a number that increments. Change a password when there is reason to think it is compromised, and otherwise leave a strong unique one alone.
Where should the randomness come from?
A cryptographically secure generator, which in a browser means crypto.getRandomValues. Math.random is not one — it is fast, seeded and predictable enough that the output should never be used for anything secret. The distinction is invisible in the result, which is exactly why it has to be a rule rather than a judgement.
Is a random UUID v4 safe to use as a password or API key?
No. A UUID v4 is an identifier with six structural bits and 122 random bits, but its standard does not define it as an authentication secret and warns against treating possession as authority. Use a purpose-built token or password with the length, rotation and storage rules of that security boundary.