I'm trying to find the best degree of entropy for a password template, and after carrying out several tests, the best result came from this: à.

This symbol alone adds 160 characters to the set (contrary to lower-upper case letters, numbers, or even symbols) and is readily available from a Spanish keyboard such as the one I use, which looks perfect.

However, I can't find any information about this, all password generation software seems to avoid using those, and I don't know why.

A password like +9qQ¨{^ adds up to 254 charset size, +9qQ¨{^aaaa has 67 bits of entropy already, setting the ease-to-remember factor aside, is there any reason to avoid using these special characters?

  • Comments are not for extended discussion; this conversation has been moved to chat. – Rory Alsop Feb 7 '20 at 15:36
  • 1
    The entropy of à is 0 btw. – PeeHaa Feb 7 '20 at 21:37

12 Answers 12


Most of the so-called password strength checkers understand neither passwords nor entropy correctly. I have always found something ridiculous that passes as a strong password. Try your name plus your birthdate (with dots or slashes, as your locale requires). There's your upper and lowercase, special characters and numbers right there, and yet nobody in their right mind would recommend that as a password.

And yet "JohnDoe01.01.1980" scores "220 trillion years" on https://howsecureismypassword.net/ and 100% on http://www.passwordmeter.com/.

https://www.my1login.com/resources/password-strength-test/ is the only checker I found that understands the stupidity - enter this example and watch how its estimate goes from "fantastic" to "medium" as you enter the last number and it "gets" that there's a calendar date.

So: Use more than the primitive entropy calculation engines to judge passwords.

For your specific case that means:

on paper extending the character set dramatically increases the search space, and should make passwords radically more secure. in reality 99.9% of users will use their own locale and a spanish a or a german umlaut are just a few additional characters, and not the entire UTF-8 space. Because you'd be silly to assume that an attacker doesn't take basic human nature into account.

There are also the usability aspects. I once had to log into my account remotely from a japanese Internet cafe, and that was decidedly not fun. If my username, password or any of the commands I needed had included non-ASCII characters, I don't think there would have been any way of making that happen.

If it is remotely possible that you may have to log into your machine from a different keyboard then the one you are using now, too-special characters will keep you out of your own account better than a forgotten password could.

And let's not even talk about Unicode and its many broken implementations, which could cause additional issues.

These are also some of the reasons password generators avoid non-ASCII characters:

Not enough added security to compensate for all the potential problems.

And please, please, pretty please - stop thinking about password complexity. It's a snakeoil strawman bridge. Length beats complexity any day and if you're using password generators you are probably also storing them in a password manager and don't care if you type 10, 20, 40 or 200 characters.

The #1 best hint for password security is to use a new, long, random password for every Internet site you register with, so your password isn't lost in the next hack. Because you can't be sure they properly hash and salt them, and if they don't then all the complexity and special characters in the world don't matter one bit.

  • 2
    You might enjoy github.com/dropbox/zxcvbn – Luc Feb 6 '20 at 13:20
  • 1
    @Luc - yes. The first paragraph is enough to know they've got their heads on the right way. They start from a list of known passwords. I always tell everyone who asks for advice to enforce a reasonable minimum length and check against password blacklist of common passwords plus your company name, location, etc. – Tom Feb 6 '20 at 13:48
  • 1
    That sounds exactly right! Also happens to be in line with NIST's recommendations, by the way, in case you ever want to tell people that you have some official source for claiming that :) – Luc Feb 6 '20 at 13:49
  • 2
    my1login uses zxcvbn internally (a quite old version of it at that because it thinks that a#a#a#a#a#a is a great password). – Konrad Borowski Feb 6 '20 at 14:36
  • @Luc - I celebrated the day when NIST finally changed their recommendations to a shorter version of what I've been talking about at security conferences for roughly five years before that. :-) – Tom Feb 6 '20 at 17:32

Language-specific characters are typically avoided by password generators because they would not be universally available (US keyboards don't have accented characters, for instance). So don't take their omission from these tools as an indication that they might be weak or problematic.

The larger the symbol set (a-z, A-Z, 0-9, etc.) the larger the pool of possible characters to try to guess when bruteforcing a password. Adding language-specific characters adds to the pool, and that can be a good thing.

But be careful about how you calculate entropy. The string ààààààààààà doesn't have a lot of entropy if you are just hitting it on your keyboard because it's convenient. Entropy is about how the characters are chosen. A randomly chosen string has high entropy and a randomly chosen string from a wide pool of characters has higher entropy.

  • 41
    I once had to change my Amazon password as I was signing in on a Smart TV and the on-screen keyboard didn’t have a symbol I’d used. A ~ if I remember correctly. – Darren Feb 5 '20 at 7:25
  • 29
    I remember an instance where using "ß" in a Windows-Login only worked when not connecting via RDP – npst Feb 5 '20 at 12:57
  • 8
    I recently generated a password with an ampersand, and then changed it when I remembered I'd need to escape it when I put the password in an xml file. – IllusiveBrian Feb 5 '20 at 14:52
  • 13
    Another argument in favour of the battery staple method of password generation. Especially on smartphones or tablets, a longer password consisting only of lower-case letters and spaces is so much easier to type in correctly than a shorter string of random garble. – Shadur Feb 6 '20 at 5:50
  • 1
    @njzk2 yes, I know you can create the mappings, but as someone who normally does not need to type ç, and my keyboard doesn't have it, to have a password generator supply it means that I have to customise my keyboard input to allow it. And then it would have to supply the instructions on what to do. – schroeder Feb 7 '20 at 8:01


All passwords should only contain printable ASCII characters. Not "Extended ASCII", not Latin-1, not Unicode.

The reason is that you never know what is actually received by a program when you press "à" or similar.

In many version of "Extended ASCII", "à" is encoded as (hex)85.
In ISO Latin-1, "à" is encoded as (hex)E0.
In Unicode "à" is codepoint U+00E0. When encoded with UTF-8, the result is (hex)C3(hex)A0.

Justin Time points out in a comment that there is another possibility. Even if everybody talks Unicode, "à" can be stored in different ways. There is U+00E0 as listed above, but there is also a composed version (U+0061 U+0300) which is "a" followed by (COMBINING GRAVE ACCENT). A correctly written program will handle this, but it is extremely common to have bugs in this area.

Anybody who has a national character in their name or address has seen them mangled in many different ways. When this happens, it is just ugly, but the letter usually gets delivered anyway.

When this happens to a password, the result is that you cannot log in! Just don't go there.

  • 32
    By this logic we all should only use six alphanumeric characters, because on some sites the data is still stored in some sort of ancient 1950's mainframe that only has six positions to store the (unhashed) passwords. So no, you should not cater to people poorly implementing login forms and the encodings of their web applications and databases. Unicode has been around for long enough now. – CodeCaster Feb 5 '20 at 11:45
  • 52
    @CodeCasterCo you're being unreasonable. This makes a lot of practical sense. See the logical fallacy Appeal to Extremes. – user1717828 Feb 5 '20 at 11:58
  • 28
    On the contrary, I think CodeCasterCo is right. This is 2020. If there's a system that does not support Unicode strings yet, it should be ashamed of itself. Now, sure, if you find such a system and need to use it - use a simple password. But wherever you can, nonstandard characters will only make your password better. And when you're building your own system there's no reason at all to put in such an artificial requirement. – Vilx- Feb 5 '20 at 12:31
  • 13
    @user1717828 yes, I know my logical fallacies and when to use them. But this advice goes against any common sense. It is, quite literally: "Some programmers don't know how character encodings work, so you better not use special characters in your passwords anywhere". There are practical arguments for not using such characters, ease of entry being a big one, but the argument made in this answer makes little sense. Especially given it starts with "All passwords should only contain printable ASCII characters", which is a hasty generalization. Look it up on your site. – CodeCaster Feb 5 '20 at 13:33
  • 30
    Perhaps a better example would be to point at how certain symbols can have multiple Unicode encodings yet be visually identical, such as, e.g., precomposed character à (U+00E0) versus decomposed character (U+0061 U+0300). It's entirely possible that using à could result in the password being refused or accepted depending on the input method, since the single keypress and key combination versions are liable to be different byte sequences. This is, sadly, a known issue with Unicode, and one yet to be normalised IIRC. – Justin Time - Reinstate Monica Feb 5 '20 at 20:35

To calculate entropy, you need a well defined method of generating random strings. Consider the following string.


If you told a computer with good random number generator to generate 6 lowercase letters and just happened to get this particular sequence, then you have log2(266) bits of entropy (28 bits of entropy). However, if your random string generator always returns "abcdef", then you have effectively 0 bits of entropy. Entropy calculations assume attackers know how you generate your passwords.

In your question, you specifically mentioned à character. You didn't specify an algorithm, so let me propose one. Pick any particular password generation algorithm (the choice doesn't matter), and always put à at end of it. How many bits of entropy does this add? The answer is 0 as the number of possible passwords that could be generated did not change.

But let's say you modified an algorithm that generates random characters to add à character into possible output characters. Doing so will add log2((alphabet + 1)size) - log2(alphabetsize) bits of entropy. This doesn't provide all that much value, for 50 characters random passwords with alphabet size of 62 (lowercase + uppercase + digits), this will merely add a single bit of entropy. You can get much better result by adding 1 character to a password, which adds about 6 bits of entropy.

Additionally, adding à to your alphabet introduces a cost of having a character that isn't necessarily on any keyboard you may want to type the password on.


It can be bad if the login system is poorly implemented. Given that I still seem to see a lot of systems that (possibly for legacy reasons) still have maximum password lengths and have silly password rules about what characters are allowed (or worse, disallowed), I do not trust non-ASCII characters to make it through unscathed with a high degree of confidence. It certainly would be bad if you were allowed to set the password with a non-ASCII character but that the login process mangled it.

For systems that do enforce maximum password lengths, you also have to consider the ambiguity of how password length is actually measured. Is it a number of bytes? In what encoding? Is it a number of code points? Number of grapheme clusters? For example, if a system limits password length based on the number of bytes in UTF-8, then using a non-ASCII character would consume more bytes and could reduce entropy.


While a number of answers have provided solid information regarding entropy, the question asked was "... is there any reason to avoid using these special characters?"

Some computer password systems will only accept alphanumeric characters plus a limited range of characters such as an underscore (_) or hyphen (-). All other characters are forbidden.

In some complex applications there can be legacy systems using screen scrapping that can corrupt the translation of special characters in text strings. The catch is you can not know how an application has been implemented.There may or may not be legislation setting minimum standards.

At any point in a chain where character sets are changed there is the possibility of special characters being dropped or corrupted.

Don't assume the application that accepts your initial password for registration is the same application that accepts your password for validation. I must admit if I every experienced a system that badly implemented I would avoid the system like the plague.


Entropy is not a property of passwords. It is a property of password generation methods (or more generally, a property of probability distributions). Specifically, it is the expected number of bits of information that an attacker would need in order to identify the specific password that was generated, assuming they know the method that was used. If all possible passwords that you might generate have the same probability, this simplifies to an entropy of log2(number of possible passwords).

  • So if your method is to select à, you have an entropy of 0; no additional information is needed to identify which of the single possible passwords was selected.
  • If your password is a sequence of somewhere between 1 and 16 às, you have an entropy of 4, since there are 16 possibilities and log2(16) = 4.
  • If your password is three numbers between 0 and 15 inclusive, selected uniformly and independently, your entropy is 12, since there are 163 possibilities and log2(163) = log2(16)*3 = 12.

    But the password 15 3 7 doesn't have an entropy, because it's not a probability distribution; it's an item that was selected from one.

Tools that claim to give you the entropy of a password are actually guessing as to what method you likely used to generate that password (and almost certainly guessing wrong), and giving you the entropy of the method they think you used. They report a high entropy for passwords with special characters because they believe the password was selected using a method that might have generated any special character in any position. If this assumption is false (which it is), then the entropy they report is nonsense.

Using special characters in passwords is neither good nor bad. It doesn't matter which characters might end up in your password. It matters how many possibilities there are.


It depends where and how you use the password.

If you're using a password manager e.g. on a usb stick, there is no problem that the password is typed-in correctly on all machines, due to copy and past.

When you have to use the password on special devices (smart TVs, fridge, devices where you can't insert a USB stick or aren't allowed to) or when there is a reasonably high chance the login process is shitty implemented, then I would only use ASCII characters found on US-Keyboards.


Yes, in some cases. For example:

1) If it is a situation where the password must be remembered, adding or requiring special characters reduces security because it increases likelihood that users will violate password policies around not storing them, or will just write those passwords down. Either case causes a much greater security risk than having less complex passwords.

Also for example, consider this series of passwords, changed every 90 days and using special characters to meet an excessive password requirement:


Imagine the first two passwords were exposed... Even after changing to the third password, it would be easy to guess the current password on seeing the first two.

2) Adding entropy for entropy's sake can be a waste of resources better spend solving other security issues. If locking down a system (for example vs. a file), you would get more benefit from making sure all other avenues of attack are blocked... Meaning, making a rock-hard prevention of any extensive repeat guessing is far better than trying to make a password where more guesses are required.

If you have nothing better to do and the password does not need to be held in human memory or typed (or at least not typed from unknown / potentially different systems) though, it would not necessarily be harmful.

  • "users will cheat or write down their passwords" Writing down passwords may not be bad, depending on the situation. What do you mean by cheating? "Imagine the person wrote the first two of those down" Why would anyone write down historic passwords but not the current one? Maybe someone would write down the first and the number that they're at, but the scenario where each is written down except the current one seems very unlikely. "making a rock-hard prevention of any extensive repeat guessing is far better" but this question is about the user, not the sysadmin. I can't do that as a user. – Luc Feb 6 '20 at 12:41
  • Regarding this being about the user, I'm not sure. I don't see a common understanding of the word "template" in this context. I took the question to be about developing a template for password requirements. But yeah... it's a bit ambiguous. Regarding "cheating" I'll clarify in the post... I meant cheating on policies that you are not allowed to write your password, etc. – HumanJHawkins Feb 6 '20 at 17:50
  • Regarding writing down the first two but not the third, I'll also clarify. That was simply intended to represent all cases where prior passwords are exposed. One should not use patterns that allow guessing todays password based on knowledge of past passwords. – HumanJHawkins Feb 6 '20 at 17:53

No, it's not bad to use “special” (better: non-ASCII) characters in passwords.

As a user, all you have to do is

  1. trust the website that it will never come up with a non-UTF-8 login form,
  2. make sure you will always be able to type your password when you need to do so.

If you know you may have to type your password on a foreign physical keyboard, you must be able to remember (or else, to look up) the position of the keys that produce your non-ASCII character(s) (BTW, à on a Spanish keyboard is 2 keystrokes). As for the layout, all operating system will let you change it, so that's not a problem.

The advantage of non-ASCII characters is that password cracking software is, IMHO, unlikely to try them out. If it did, it would explore passwords with a lower probability, at the expense of longer ASCII passwords, which have a higher probability of being used.


Extended ASCII (0-255) is fine as you can dial them anyway by using alt+ numerical keypad.

Any other character outside extended ASCII will not always work because your possibility to write it is dependent on the specific system configuration. Some systems may be locked/configured not to allow anything UTF-like.

So if you have a specific system and a specific language set, you may use something special for your login, but if you need a password to work from anywhere on any system, do limit yourself to ASCII.

Something like these will give you quite a lot of entropy and be generally not tested by most password brute-forcers:


I used to even use 3-4 character passwords (for things like lab system accesses) many years ago since the characters were not on the keyboard.

Statistically, a brute-forcing software that is adapted for a specific region will also much more likely hit successes on UTF-8 compared to using extended ASCII.

  • 1
    I specifically said extended ASCII, which is up to 255. – Overmind Feb 6 '20 at 9:20
  • Added extended. I used 0-255 anyway, to be clear. – Overmind Feb 6 '20 at 11:40
  • 1
    You will have much fun trying this in different locales or non-Windows machines ;-) – René Feb 6 '20 at 12:53
  • This makes no sense at all. Since it's too much to write in a comment: pastebin.com/f4HTpdnX – Luc Feb 6 '20 at 13:12
  • If you use n character password out of an m character set, you have n lg(m) bits of entropy. This doesn't matter whether it's encoded in an eight-bit character set or UTF-8. If you're searching for a password that's [a-zà], it'll take the same time to search the same 27 passwords, Unicode or not. – prosfilaes Feb 7 '20 at 4:01

I use Unicode characters in passwords, and sometimes a password change is blocked (forbidden characters), or goes through and then requires a password reinitialisation (some encoding problem). It’s very system dependant.

Not the answer you're looking for? Browse other questions tagged or ask your own question.