Unicode Characters in Passwords

Unicode Passwords: Expanded Security or Hidden Complexity?

Unicode encompasses over 149,000 characters across 161 scripts, dwarfing the 95 printable ASCII characters. Using Unicode in passwords dramatically expands the character pool — but introduces significant complexity that both users and developers must understand.

The Entropy Advantage

If a password uses characters from a Unicode-aware pool:

ASCII (95 chars):  6.57 bits/char → 12 chars = 78.8 bits
Unicode common subset (~5,000 chars): 12.3 bits/char → 12 chars = 147.6 bits
Full Unicode (~149,000 chars): 17.2 bits/char → 12 chars = 206.4 bits

Even a modest Unicode pool provides nearly double the entropy per character compared to ASCII.

NIST's Stance on Unicode

NIST SP 800-63B states:

"Verifiers SHOULD accept all printing ASCII characters and the space character in memorized secrets. Verifiers SHOULD also accept Unicode characters."

This means modern authentication systems should allow Unicode input, though practical challenges remain.

Normalization: The Critical Challenge

The same visual character can have multiple Unicode representations:

"é" can be:
  U+00E9  (single code point: LATIN SMALL LETTER E WITH ACUTE)
  U+0065 U+0301  (two code points: "e" + COMBINING ACUTE ACCENT)

If the system does not normalize input consistently, a user who types "é" one way during registration and another way during login will be locked out. NIST recommends using NFKC normalization (Unicode Normalization Form KC) before hashing.

Encoding Pitfalls

Truncation at Byte Boundaries

bcrypt truncates input at 72 bytes. A UTF-8 encoded password with multi-byte characters reaches this limit much sooner:

ASCII "a" = 1 byte  → 72 characters before truncation
CJK "中" = 3 bytes  → 24 characters before truncation
Emoji "🔒" = 4 bytes → 18 characters before truncation

Argon2id has no such limitation.

Database Storage

Some databases or ORM configurations silently convert Unicode to ASCII or truncate multi-byte characters. Test the full round-trip: input → normalization → hashing → storage → comparison.

Practical Unicode Strategies

Approach 1: Accept and Normalize (Recommended)

input → NFKC normalize → hash with Argon2id → store

This follows NIST guidance and gives maximum flexibility to users worldwide.

Approach 2: Accept ASCII Only

Simpler to implement but excludes non-English users and limits the character pool. Acceptable for systems where all users share the same keyboard layout.

Approach 3: Accept Unicode, Hash with Pre-processing

input → NFKC normalize → SASLprep (RFC 7613) → hash → store

SASLprep removes control characters and ensures consistent representation. Used in protocols like SCRAM authentication.

Strength Analyzer Considerations

A Unicode-aware password strength analyzer should:

1. Recognize Unicode characters as expanding the effective pool
2. Apply NFKC normalization before analysis
3. Calculate entropy based on the script/block actually used (not the full Unicode range)
4. Warn about compatibility — some systems may not accept Unicode passwords
5. Account for bcrypt truncation if the target system uses bcrypt

Real-World Gotchas

• Emoji passwords look fun but cause problems with bcrypt truncation and cross-device input
• CJK characters provide excellent entropy but may be difficult on non-native keyboards
• Right-to-left scripts (Arabic, Hebrew) can cause display issues in password fields
• Copy-paste may include invisible Unicode characters (zero-width spaces, direction markers)