Strong Password Rules and Secure Identifiers: Length, Randomness, Storage
Short passwords that look complicated lose to long ones that look boring. The arithmetic behind length, where randomness comes from, storage habits, and where UUIDs belong.
What protects an account is not how complicated the secret looks but how many possibilities it was drawn from. The most common mistake in building a strong password is confusing those two things: eight characters sprinkled with punctuation are dramatically weaker than sixteen plain ones. This article explains why that is true, how generation should actually work, and where machine identifiers fit into the same picture.
On the generation side, the password generator lets you set length and character set, while the UUID generator covers identifiers that must not collide across systems. For reading encoded values out of configuration files there is the Base64 encoder and decoder, and the character counter is handy for checking length requirements.
Why a strong password starts with length
The cost of a brute-force attack scales with the number of possible combinations. Enlarging the character set multiplies that number; adding characters raises it to a power. One extra character therefore buys far more than ten extra symbols in the alphabet ever will.
Concretely: twelve lowercase letters cover far more ground than eight characters drawn from every symbol on the keyboard. The second option nevertheless looks safer because it contains punctuation. Appearances are irrelevant here; the thing counting the possibilities is a machine.
Length against character set
| Length | Lowercase only | Letters + digits | Full character set |
|---|---|---|---|
| 8 characters | Very weak | Weak | Not enough |
| 12 characters | Moderate | Good | Good |
| 16 characters | Good | Strong | Very strong |
| 24 characters | Very strong | Very strong | Overkill |
| 32+ characters | Beyond useful | Beyond useful | Beyond useful |
The practical reading is straightforward. Sixteen characters across the full set is more than enough for everyday accounts. The generator accepts a length between 8 and 128 and defaults to 16, and that default is aimed squarely at this balance. Reach for the lower bound only when a legacy system forces you to.
Where randomness comes from
Human beings are terrible random number generators. Strings we invent carry keyboard geography, birth years and fragments of familiar words without our noticing. Attack dictionaries target exactly those patterns; anything that comes naturally to mind has already been enumerated.
So the job belongs to a machine. A good generator draws from an unpredictable source and gives every character in the set an equal chance. A bad one draws from a predictable counter, and although its output looks random to a person, it can be enumerated in order.
What the generator settings actually change
Beyond length, two settings matter: which character classes are enabled, and whether look-alike characters are excluded. Lowercase l, uppercase I and the digit 1 are indistinguishable in many typefaces, so excluding them cuts transcription errors when a value has to be typed by hand. The exclusion narrows the possibility space only marginally, and one or two extra characters more than repay it.
A second practical concern is where the generated value goes next. Clipboard history tools, draft fields in chat applications and browser autofill can retain it without your noticing. Pasting straight into the destination field and avoiding intermediate stops is a simple habit with a real payoff.
Passphrases
Four or five randomly chosen words make a reasonable alternative for the handful of secrets you actually have to memorise. The condition is that the words really were chosen at random; a line from a song you like does not qualify. This approach only makes sense for memorised secrets. Everything else belongs in a manager.
Storing and sharing a strong password
Generating is the easy half. The hard half is deciding where the value lives afterwards.
- One value per account. A single breach unlocks every account that shares the secret. Reuse is a much larger risk than length ever was.
- Use a password manager. Nobody memorises thirty long random strings, and writing them in a notebook is the worst available answer.
- Turn on a second factor. An authenticator app or a hardware key protects an account even after its password leaks.
- Split the channel when sharing. Never send the value and the account it belongs to in the same message.
- Rotate on suspicion, immediately. The moment you think a value may have been exposed, change it. “It is probably fine” is an expensive sentence.
One detail gets skipped almost universally: cleaning up old values. Keys forgotten inside server configuration, throwaway scripts and screenshots are the most common source of leaks that surface years later. When you rotate a secret, go looking for everywhere the previous one was written down.
Identifiers: unique is not the same as secret
A UUID is a 128-bit value used to produce identifiers that will not collide across systems. It replaces the incrementing counter behind order numbers, filenames and session records, and it guarantees that two servers generating values at the same instant will not clash. The generator produces up to 100 values in one go, with five as the default.
The critical distinction: being unique is not being secret. An identifier appears in the address bar, lands in log files and travels to third-party analytics. Using one as a password, as a session token, or as the “anyone with the link” part of a private URL is therefore a mistake. Anywhere confidentiality is required, use a value designed to be unguessable instead.
There is a side benefit to replacing counters with identifiers: they leak nothing. A sequential number tells the outside world how many records you hold and how fast that figure grows. An identifier tells them nothing at all.
The rules are clear for personal accounts. Where it gets messy is shared access. A social media account, a domain registrar or a payment provider often ships with a single login, and over time that login spreads to four or five people. When somebody leaves, nobody can say with confidence which accounts they still hold.
Three steps make it manageable. First, inventory: which accounts exist, who holds them, at what level of access. Second, move to individual logins wherever possible; most services now support team membership and no longer require a single shared credential. Third, for the small number of secrets that genuinely must be shared, keep them in a common vault that records who opened what.
The offboarding list has to be short enough that it actually gets used: rotate the values in the shared vault, revoke individual access, remove their second-factor devices, and end saved sessions on shared machines. Writing those four lines into the leaving process beats trying to remember them afterwards.
Frequently asked questions
Should I rotate passwords every ninety days?
Forced periodic rotation is no longer recommended, because under that pressure people produce predictable variations, typically by bumping a trailing digit. Tie rotation to events instead: a suspected breach, a shared device, a departing colleague.
Are browser-suggested values safe?
The strings browsers generate are usually long and genuinely random. The open question is storage: a browser vault is less resistant to someone with physical access to the machine than a dedicated manager is.
Does removing symbols from the character set hurt?
Some systems reject particular punctuation, which forces you to narrow the set. Compensating is trivial: add two or three characters of length and the balance is more than restored.
How do I find old keys left in configuration files?
Comparing two revisions is the fastest route: put the old and new configuration side by side in the text diff checker and forgotten lines stand out immediately. When reviewing who connects to a server and from where, WhatsMyIP is a quick way to confirm your own address; access from a network you did not expect is often the first sign of a key that escaped.
What is the actual risk of reusing one value?
After a breach at one site, attackers replay the same email and password pair against hundreds of other services. The technique is common enough to have its own name. A single instance of reuse can neutralise even an excellent secret.
For keeping these values tidy inside configuration files, see the naming discipline in working with JSON data; if a shared link has to travel onto printed material, the QR code usage guide takes it from there.
