Lookalike characters are symbols or letters that are visually similar, such as zero and the letter O. They can make secrets harder for humans to read, transcribe, and troubleshoot. Excluding them improves usability in some contexts, but teams must balance that convenience against the character set required by the target application.
What Lookalike Characters Mean in Secrets and Credentials
Lookalike characters are visually similar symbols or letters, such as 0 and O, that can be mistaken for one another when humans read, copy, or troubleshoot secrets. Their impact is usually practical rather than cryptographic: they increase the chance of transcription errors, verification delays, and support friction when a token, password, or key must be handled manually.
The issue is most visible where secrets are exposed outside automated flows, for example during onboarding, break-glass use, incident recovery, or vendor support. In those moments, readability matters because a single character error can prevent access, create lockouts, or lead teams to treat a valid secret as broken.
Why They Matter for Usability and Supportability
Secret formats are a design choice. Excluding ambiguous characters can make a value easier to transcribe and validate by eye, especially if humans may need to read it from a screen, paper, or ticket. That benefit is strongest when the secret must be communicated verbally or retyped under pressure.
The trade-off is character-space reduction. Removing lookalike characters narrows the alphabet available to the generator, so teams need enough length and entropy to preserve strength. Usability improves when the format is easier to handle, but only if the application still accepts the resulting character set without accidental rejection or silent normalization.
Where Ambiguity Becomes a Security Design Issue
Lookalike characters are not a vulnerability by themselves, but they can shape how safely a secret can be operated. When a secret is hard to transcribe, users may store it insecurely, reuse it, ask for it to be repeated over insecure channels, or introduce errors during emergency handling. Good design reduces those handling mistakes before they become operational incidents.
They also matter in verification workflows. If teams compare secrets manually, ambiguous characters can hide whether two values match, especially in logs, screenshots, or helpdesk notes. For that reason, the safer pattern is to rely on copy-paste, structured secret delivery, and automated validation rather than human interpretation.
How Teams Should Think About Format Choice
The right format depends on how the secret will be used. A machine-only secret can often use a broad character set because automation handles it reliably, while a human-facing code, recovery string, or bootstrap secret may benefit from a reduced set of unambiguous characters. The decision should follow the target application’s requirements, not a blanket rule.
Teams should also test the full path that secret values travel through. Some systems silently transform characters, strip punctuation, or alter casing, which can erase the usability benefit of a carefully chosen alphabet. A format is only as good as the systems that store, transmit, display, and validate it.
Risk and Threat Considerations
Lookalike characters create a human-error risk that can turn into availability problems, support overhead, or insecure workarounds. The danger is greatest when secrets are handled manually during recovery, provisioning, or escalation, because ambiguity increases the odds of mistakes at the exact moment accuracy matters most.
Failure mechanism: A person misreads, mistypes, or verbally transcribes a secret that contains ambiguous characters, then the receiving system rejects it or accepts the wrong value as operational truth.
Impact: The result can be failed authentication, delayed recovery, repeated lockouts, or unsafe fallback behaviour such as reissuing secrets over weak channels.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers secret generation and handling where human transcription errors affect authentication |
| IA-2 — Identification and Authentication (Organizational Users) | Applies when ambiguous secret handling can disrupt user authentication workflows | |
| Recommendation — Choose a secret format that supports reliable authentication without forcing manual transcription. Use authentication methods that minimise manual entry of ambiguous secret values. | ||
| CIS Controls v8 | CIS-5 — Account Management | Supports account and secret handling practices that reduce operational mistakes during access use |
| CIS-16 — Application Software Security | Applies where application input rules and secret formats must be validated consistently | |
| Recommendation — Standardise account and secret handling so users do not rely on error-prone manual transcription. Validate secret format rules consistently so the application accepts only intended character sets. | ||
Practitioner Guidance
What to watch for: Use a reduced character set when humans must handle the secret directly, but keep the overall entropy sufficient for the application’s security requirements. If a secret is machine-only, readability is usually less important than compatibility and strength.
Governance implication: Treat secret format as part of the control design, not just a developer convenience. The best choice is the one that matches the operating context, prevents avoidable transcription errors, and still satisfies the target system’s accepted character rules.
Related resources from NHI Mgmt Group
- How should security teams handle lookalike domains that mimic verification flows?
- What breaks when invisible Unicode characters are not checked in code and AI rules files?
- Why do lookalike domains remain effective even when email authentication is in place?
- Why do lookalike domains still work against trained users?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org