Passwords, codes and file identity: what proves what

Entropy is the measure, not the look

A password's strength is the number of guesses an attacker needs, which is the log base two of the number of possible values. A random string of 16 characters from a 94-character alphabet has 16 × log₂(94) ≈ 104.9 bits; a 12-character one has about 78.6 bits. A passphrase from a 256-word list gives exactly 8 bits per word, so six words is 48 bits — fine against online guessing, weak against an offline attacker with a fast hash.

Length dominates because entropy grows linearly with it while the alphabet contributes only logarithmically. Complexity rules (“one symbol, one digit”) add a little entropy and a lot of unusability; a longer random value is the better trade. The generator shows the real entropy rather than a coloured bar, because the bar is an opinion and the bits are arithmetic.

One-time codes are time, not secrecy

TOTP derives a six-digit code from a shared secret and the current 30-second counter. The secret is the long-lived credential; the code is a short proof that the holder has it. Verifiers normally accept the previous and next window as well, which gives about ±30 seconds of tolerance, and that is why a device clock minutes out of sync fails even with the right secret.

The code does not prove identity by itself: anyone who has the secret can generate it. It proves possession of the secret at that moment. Treat the secret as the password — never paste it into a page you do not trust, and never store it in a screenshot.

UUIDs are unique, not secret

A version-4 UUID is 122 random bits, formatted as 8bd5db30-a642-4c83-8073-1ac523956619. That is enough to make collisions negligible, and it is not enough to make the value unguessable in the sense a secret is: it is designed to be published as an identifier. Using a UUID as an access token — “the link is unguessable, so it is private” — is a common and dangerous substitution. A token needs its own secret and its own expiry.

The first bytes beat the extension

A file's extension is a label a user or a program chose; its magic bytes are what the content actually is. Measured: the eight bytes 89 50 4E 47 0D 0A 1A 0A identify a PNG image. If the same bytes arrive in a file called photo.txt, the inspector reports “Mismatch: the name says .txt, but the bytes are PNG image.” That mismatch is the interesting signal — a renamed executable, a mislabelled download, or a file that will be opened by the wrong program.

Magic bytes are evidence, not proof of safety. A file can be a valid PNG and still contain a crafted payload in its metadata, and a polyglot file can satisfy two formats at once. Use the signature to decide what a file is, and a separate scanner to decide whether it is safe.

Entropy versus policy

A site's password policy is not a measure of strength. Requiring a symbol and a digit while allowing eight characters can produce less entropy than a sixteen-character passphrase, and it encourages predictable substitutions (a for @, o for 0) that attackers try first. The useful policy is a minimum length, a check against breached-password lists, and no composition rules; the generator's entropy figure is the number to compare, not the number of character classes ticked.

Where to keep each value

A password belongs in a password manager, not in a note or a spreadsheet; the manager's job is to make a unique long value per site practical. A TOTP secret belongs in an authenticator app or a hardware key, and its recovery codes belong somewhere offline — losing the device without them locks you out. A UUID belongs in the database or URL as an identifier; it can be logged and shared. A file signature is evidence read at inspection time, not a value to store.

The failure mode is treating one as another: putting a TOTP secret in a password field, using a UUID as a bearer token, or trusting a file because its extension matches. Each is a category error, and each is common because the values all look like opaque strings.

What each value proves