Two account identifiers can be different to software while looking almost identical to a person. That gap matters anywhere people use a displayed identifier to decide whom they are trusting: administrator consoles, collaboration tools, package registries, marketplaces, support systems, or internal approval workflows.

If an application treats visual appearance as irrelevant, an attacker may be able to register an identifier that resembles a trusted account closely enough to mislead another user. The database still sees two distinct strings. The human may not.

The defensive goal is not to ban international text. It is to decide which identifiers are security-sensitive, define what forms they may take, detect dangerous visual ambiguity where it matters, and avoid making display names carry authority they were never designed to carry.

Start with the real trust boundary

A useful mental model is:

stored identifier -> application display -> human recognition -> trust decision

The application controls the first two stages, but the security decision may happen in the third and fourth.

Suppose a system has a privileged account named support. A newly registered identifier contains a character from another writing system that is rendered very similarly to one of the Latin letters. The two strings have different Unicode code points, so an ordinary uniqueness check can correctly store both.

That uniqueness check answers only this question:

Are these two identifiers the same string under the application’s equality rules?

It does not answer:

Are these identifiers easy for a person to distinguish in the interface where trust decisions happen?

Those are separate security properties.

Understand confusables without treating Unicode as the problem

Unicode supports many writing systems. Some characters from different scripts have similar or, in some fonts, nearly identical shapes. Unicode security terminology calls strings that can be mistaken for one another confusable.

For example, a Latin letter and a Cyrillic letter can have similar visible forms while remaining different characters. Similarity can also occur within one script, and the exact appearance depends on fonts and rendering.

The important point is that visual similarity is not the same as Unicode equivalence.

Unicode normalization addresses cases where text has different code-point sequences that represent equivalent text under a defined normalization form. Confusable detection addresses a different problem: distinct characters or strings that may look alike to people.

Therefore, normalizing an identifier does not by itself solve visual spoofing.

Decide which names are identifiers and which are labels

Many applications make one field do two jobs:

username = account key + public display label

That design makes every usability choice about names part of the security model.

A clearer design separates a stable account identifier from a user-facing display name when the product allows it:

account_id:   8f1...       stable internal identity
username:     northwind    constrained unique handle
display_name: North Wind   flexible presentation text

The exact fields depend on the product. The principle is that text used to identify authority should have stronger ambiguity controls than text used only for presentation.

A display name may legitimately contain spaces, punctuation, multiple scripts, or duplicate values. A unique handle used in mentions, approvals, ownership displays, or administrator searches may need a more restrictive policy because people rely on it to identify an account.

Do not silently turn a display name into an authorization key. Authorization should use a stable internal principal identifier, not whichever spelling is currently shown to a user.

Use an identifier profile instead of ad hoc character rules

A security-sensitive identifier should have a documented identifier profile: a policy defining which characters and combinations the application accepts.

The right profile depends on the users the system must support. A service intended for one organization may reasonably use a narrow repertoire for privileged handles. A global public service may need many scripts and should not force all users into ASCII merely for implementation convenience.

Useful profile decisions include:

  • which Unicode characters are permitted in the identifier;
  • whether identifiers may mix writing scripts;
  • how case is handled for comparison;
  • which Unicode normalization form, if any, is applied before uniqueness checks;
  • maximum length after the application’s chosen representation is established;
  • whether certain high-value names are reserved.

Unicode Technical Standard #39 defines security mechanisms and data for identifier restrictions, mixed-script analysis, and confusable detection. Applications do not need to invent visual-confusability tables themselves. Use a maintained implementation that follows an appropriate Unicode version and document any product-specific restrictions.

A profile is a policy boundary, not a claim that every accepted identifier is harmless. Even identifiers made entirely from one script can be visually confusing.

Treat confusable detection as a warning signal, not canonicalization

Unicode confusable detection can derive an internal comparison form, commonly called a skeleton, so that visually confusable strings can be detected.

The crucial implementation lesson is what not to do with it.

A confusable skeleton is not a replacement username. It is not suitable for display, and it should not become the application’s normal canonical form for identity. Its purpose is to help answer a narrower question: whether two otherwise distinct identifiers may be visually confusable.

A simplified registration flow might therefore be:

candidate identifier
        |
        v
apply identifier profile
        |
        v
apply normal equality/uniqueness rules
        |
        v
check confusability where policy requires it
        |
        v
accept, reject, or require review

Keep equality and confusability separate. Two identifiers can be unequal but confusable, and the application may need different responses to those facts.

Protect high-value identities more strongly

Not every visual collision has the same consequence.

If two ordinary users choose similar public handles, the application may be able to reduce confusion through profile pages and additional identity context. A handle that resembles security-team, billing, a package publisher, or a system administrator can carry much greater impersonation risk.

This makes reserved-name protection useful even when the broader identifier policy is permissive.

For example, a system can maintain a small set of protected identities and reject or review registrations whose confusable form collides with those identities. The protected set might include official service accounts, administrative roles, organization names, or other identities that users are expected to trust.

This is defense in depth. It reduces a specific impersonation path without requiring every identifier in the system to follow the narrowest possible character repertoire.

Be careful with fuzzy matching beyond a well-defined confusable mechanism. Broad edit-distance or “looks similar” rules can produce large numbers of false positives and can make legitimate names difficult to register. A control that operators routinely bypass is not providing the intended assurance.

Give people more than a name when the decision matters

Identifier restrictions cannot make human recognition perfect. Interfaces should therefore avoid asking a user to approve a sensitive action from a name alone.

Consider an administrator assigning a powerful role. This confirmation is weak:

Grant administrator access to: support

The visible handle is carrying the entire identity decision.

A stronger confirmation can show independent context:

Account: support
Organization: Example Operations
Verified email domain: example.invalid
Account created: 2024-11-18

The exact attributes must fit the application’s privacy model and must themselves come from trustworthy sources. The principle is to provide independent identity cues so that one visually deceptive string is less likely to control the decision.

For especially sensitive workflows, search results and approval screens can also expose an immutable account identifier or another stable reference that administrators can verify through a separate trusted process.

State the threat model clearly

Visual-spoofing controls mainly reduce the risk that a person mistakes one identifier for another and grants trust, sends information, approves access, or chooses the wrong account as a result.

They do not protect against:

  • compromise of the legitimate account;
  • an attacker who legitimately controls the trusted identifier;
  • phishing that does not depend on a confusing identifier;
  • authorization bugs that grant the wrong principal access;
  • misleading profile photos, biographies, or other presentation fields;
  • deceptive domains or URLs unless those are covered by their own security rules.

The control also assumes that the application knows which text fields participate in identity decisions. Applying strict username rules while an unconstrained display name is shown more prominently in approval screens can leave the original problem largely intact.

Plan for policy changes

Unicode security data evolves, and an application’s own supported languages may change. That creates an operational question: what happens when a newer identifier policy classifies an existing name differently?

Avoid changing identity semantics silently.

If confusable-detection data or identifier restrictions are upgraded, test the new policy against existing identifiers before enforcing it. Existing accounts may require grandfathering, warnings, administrator review, or carefully managed renaming depending on the risk and product contract.

If the application persists derived confusability data for lookup, record enough version information to know how it was produced and be prepared to recompute it when the Unicode data or algorithm changes. Do not assume a derived security comparison value is stable forever.

Registration policy and existing-account remediation are different operations. A rule that is reasonable for new identifiers can be disruptive if applied retroactively without a migration plan.

Verify the control with adversarial test cases

Testing should exercise the policy at the same boundaries where users create and trust identifiers.

Create test cases for:

  • ordinary identifiers from every script the product intentionally supports;
  • permitted and forbidden mixed-script combinations;
  • canonically equivalent inputs under the chosen normalization policy;
  • known confusable pairs from the Unicode security data used by the implementation;
  • collisions with protected or reserved identities;
  • policy behaviour after a Unicode-data upgrade;
  • sensitive interfaces that must display independent identity context.

The expected result should be explicit. A confusable registration may be rejected in one product, sent to review in another, or accepted with a warning in a low-risk namespace. Testing should verify the policy the product actually chose rather than assuming one universal response.

Also test that authorization continues to use the stable principal identifier. Renaming a handle or changing a display name should not accidentally transfer permissions to another account.

Choose restrictions in proportion to the decision

A simple internal tool with centrally provisioned accounts may not need sophisticated confusable detection. Restricting privileged handles to a small known repertoire and preventing self-service creation may be sufficient.

A public service with global users has a different trade-off. Overly broad character bans can exclude legitimate names and languages. In that environment, script-aware identifier profiles, confusable checks around high-value identities, and richer identity cues can preserve more usability while reducing impersonation risk.

The strongest practical rule is to focus controls where visual identity carries authority.

Conclusion

Software compares character sequences; people compare what those characters look like. Security-sensitive identifiers need to account for both.

Define which fields actually identify an account, keep authorization bound to stable internal principals, use a documented identifier profile, and treat confusable detection as a separate signal rather than a canonicalization scheme. Protect high-value identities more strongly and give users independent context when they make sensitive trust decisions.

The goal is not to make every name visually unique. It is to make visual ambiguity much less likely to become unauthorized trust.

Cybersecurity Secure Design Input Validation Identity