Is it a good idea to use non-Latin Unicode characters in a password?

Question

I've heard many suggestions as to what makes a good password (hard to guess, not a dictionary word or permutation thereof, at least a certain length, etc.) so that it cannot be cracked in a realistic amount of time. However, from what I understand, password cracking techniques and software will try to use Latin characters, digits, and special characters that you would typically find on a US keyboard. Therefore, would it be a good idea to include some non-Latin characters in a password?

For example, "passw密码rd".

Answer 1

Probably not - you would find many compatibility problems depending on the supported character sets of devices that you may need to enter your password from.

There are two ways of making sure you have a strong password:

1. Use a source of entropy that the attacker isn't aware of.
2. Use enough entropy so that brute force is infeasible.

The approach your proposed method takes is the former. There are usually fewer disadvantages of the latter approach. If you use a password with at least 128 bits of entropy it cannot be guessed in a reasonable amount of time. That is on average - if the attacker is very lucky they might guess it first time - but the same is true with all passwords.

So to get 128 bits of entropy you either need a password with at least 20 completely random characters (using both case letters, numbers plus ASCII symbols) or you need 10 randomly selected dicewords.

So in my opinion this is already a solved problem. Use a secure password generator to create a random 20 character password if you don't need to remember it, or use Diceware if you do.

Answer 2

Generally, yes. Some systems may not support or allow non-latin characters. In the backend, the database and other systems need to be setup properly to handle non-latin characters or unexpected things may happen. For example, one multi-bye unicode character may be interpreted as multiple single byte characters (or whatever the expected size is in the encoding being used).

If the system accepts your input, and everywhere where you will be entering the password allows you to switch languages, you should be fine. The one catch that immediately comes to mind is if there is a maximum number of characters allowed and because you are using multi-byte characters you end of exceeding the limit or if it performs some type of truncation. There may also be some type of security filters built in assuming only latin characters are allowed, and your input could be flagged or sanitized. All of these conditions will depend on the specific system and what it supports.

You may need to test and see if there are compatibility problems; however, bonus points for you if it takes your single characters and considers it 2 or more - giving you a longer password without you needing to remember more pieces. If the system accepts your input and it works great. If you ever encounter weird problems, then you hopefully will be able to reset and use a plain latin set.

---

For reference, just doing a basic text to binary conversion:

passw密码rd = 01110000 01100001 01110011 01110011 01110111 11100101 10101111 10000110 11100111 10100000 10000001 01110010 01100100  
(9 "characters", 13 bytes) 


password   = 01110000 01100001 01110011 01110011 01110111 01101111 01110010 01100100 
(8 "characters", 8 bytes) 

In a way this is what the computer really sees. So if the system is not unicode aware it may go nuts, or may interpret passw密码rd as passwå¯ç rd, passw密码rd, etc. If the functionality is not implemented consistently throughout the system the function which saves and hashes the password may see it one way and the functions which late compare the hash may do it another way.

Answer 3

Yes, it would be a great idea to use those characters.

passw密码rd would probably not be the best example as it is simply two characters away from password, but it would certainly be more secure than password11, p4ssw0rd, or similar permutations.

Since these letters are not as convenient on average keyboards, most users will probably not use these characters as it requires extra effort during the login process. Hackers know this and will most likely not try these characters as often. That does not mean that using these characters is some key that will protect you from brute-forcing, but it would be significantly better protection. The number of possible characters greatly increases when using such unicode characters, increasing the time for a potential brute-force attack. Because of this, hackers will most likely decide to target the "low hanging fruit," being people who use a smaller character set that allows for less possibilities.

Answer 4

Well non ascii Unicode characters can cause representation problems if you have to type them from a non controlled machine for example in a hotel business center. First it could not have the expected encoding. For example é is U+00E9 or LATIN SMALL LETTER E WITH ACUTE. It is normally encoded as "\xc3\xa9" with 2 bytes in UTF-8, but is the single byte "\xe9" in Latin-1 charset.

Furthermore, it has 2 different normalized forms ⁽¹⁾. U+00E9 if the Normalization Form C (or Canonical Composition) and the Normalization Form D (or Canonical Decomposition) is U+00E5 U+0301: LATIN SMALL LETTER E with COMBINING ACUTE ACCENT. By definition, those two forms correspond to the same glyph, but almost any application whatever the language will say that they are diffent strings. And when you type non ascii characters from a keyboard, you can hardly guess what form will be used.

Long story short: when adding non ascii characters you make the entropy grow which is good, but at a risk on not beeing able to type the password from a foreigh system. And a greater length is generally a higher entropy gain that adding some non ascii characters...

---

⁽¹⁾ Unicode Normalization Forms

Answer 5

I think it'd be a very bad idea. As you don't have insight into how a website is sanitizing your password, you could easily end up with a situation where you put in some long Unicode password with a lot of entropy, which, after sanitation, ends up being stored as (a hash of) only the ASCII printable characters this password contained (or the sanitation code normalized out of your Unicode) or even as (a hash of) an empty string if it doesn't contain any.

So you'll be patting yourself on the back, thinking you have very good security, when in reality your password ends up stored as (a hash of) very few ASCII printable characters or the aforementioned empty string. So you can still login with your Unicode password, but so can anyone else that can brute-force a few ASCII characters or just puts in enough Unicode that's sanitized away (in case of stored empty string).

Additionally, if they ever change their sanitation code, you may be locked out of your account.