53

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?

Héctor Álvarez
  • 665
  • 1
  • 5
  • 7
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/104180/discussion-on-question-by-hector-alvarez-is-it-bad-to-use-special-characters-in). – Rory Alsop Feb 07 '20 at 15:36
  • 1
    The entropy of à is 0 btw. – PeeHaa Feb 07 '20 at 21:37

12 Answers12

78

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.

schroeder
  • 125,553
  • 55
  • 289
  • 326
  • 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 05 '20 at 07:25
  • 30
    I remember an instance where using "ß" in a Windows-Login only worked when not connecting via RDP – npst Feb 05 '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 05 '20 at 14:52
  • Adding an additional character length requirement helps total password entropy comparably (at least) in increasing the character set. The practical issues with non-basic-seven-bit characters mentioned need to be considered -- and users may not consider them until there's a problem. I've included a backspace control character in a password that should only have been typed on the system console -- which used ctrl-x for delete. – mpez0 Feb 05 '20 at 20:53
  • 13
    Another argument in favour of the [battery staple](https://xkcd.com/936/) 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 06 '20 at 05:50
  • us keyboard have accented characters when using the international mapping, which creates accents from deadkeys (combining various symbols with other letters). e.g.: `', c` -> `ç` – njzk2 Feb 07 '20 at 04:35
  • 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 07 '20 at 08:01
  • 1
    @njzk2 can you customize the mapping before you log into the OS? Because if you can't, that severely hampers your ability to *create* those mappings in the first place. Even if you do, remote login to a machine might still be a problem. And if you are using this *not* as your OS user password, then you need to customize the keyboard mapping on every single machine you use just to log into whatever uses the unusual strange characters. On mobile this could be quite annoying, as well. – VLAZ Feb 07 '20 at 09:44
  • 1
    Highly relevant here: https://twitter.com/FakeUnicode/status/1192245294429130752 – IvanSanchez Feb 07 '20 at 14:41
  • @IllusiveBrian What were you doing putting an unencrypted password in an XML file? – CJ Dennis Feb 07 '20 at 23:40
67

YES!

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.

Stig Hemmer
  • 2,413
  • 10
  • 14
  • 33
    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 05 '20 at 11:45
  • 53
    @CodeCasterCo you're being unreasonable. This makes a lot of practical sense. See the logical fallacy [Appeal to Extremes](https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/30/Appeal-to-Extremes). – user1717828 Feb 05 '20 at 11:58
  • 29
    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 05 '20 at 12:31
  • 14
    @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 05 '20 at 13:33
  • Now of course this answer assumes something different which is really, really bad. It assumes that you use the same password for **several** applications (or in several places). If it is indeed the same application, it doesn't matter at all what number the program gets to see. As long as they're the same bits, the password is correct, otherwise it's not. The program verifying your password couldn't care less whether it sees 0xe0 or 0x1ff43 as long as that's what it has to be. – Damon Feb 05 '20 at 17:31
  • 6
    @Damon In a world where password protected systems may be accessed from a diverse collection of client systems, if the client systems cannot be trusted to deliver the same encoding of those non-ASCII characters, a single application's password could suffer this problem. – Zarepheth Feb 05 '20 at 18:40
  • @Vilx- Does it really matter, though? To enter unicode or ascii, one has to enter some number code. Use those numbers without converting to a character. That password gains its entropy from length (and it should be about the same entropy) and can be entered anywhere. – Chieron Feb 05 '20 at 19:11
  • 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 05 '20 at 20:35
  • 4
    @Vilx- As Justin Time notes, many grapheme clusters have more than one possible representation. If someone hits "A" key and then a "grave accent" key, should that generate a single "a with grave" character, or should it generate an "a" followed by a "combining grave accent"? If someone sets a password with a terminal or browser that happens to treats that character differently from the user's normal system, how would that user know about and recover from that situation? – supercat Feb 05 '20 at 21:05
  • @supercat - Well, those sound like special cases to me. Most of the time there's just the one and only login screen, so the password gets the same treatment every time. – Vilx- Feb 05 '20 at 21:12
  • 2
    @Vilx- Different devices accessing the login screen might process keyboard inputs differently. – supercat Feb 05 '20 at 21:25
  • 3
    The argument about being locked out seems very on-point to be honest, whether the website is well-designed or not is out of the question, I've had to support very old legacy code bases that I'd rather throw away and start over, just because they work and updating them takes resources, so it's not viable to do so. That said, I'm a bit concerned about the safety of my password in those systems, on most cases the encryption is handled very poorly, I've seen PMs happy to encrypt passwords as MD4 or Base64, only to have the database hacked and data stolen... Maybe it's for the best to hash it wrong – Héctor Álvarez Feb 05 '20 at 21:40
  • 3
    A potential situation that comes to mind, @Vilx-, is when the login screen accepts key combinations to enter special characters (e.g., `Ctrl+\`, a`), but those characters can also be entered by discrete buttons on certain keyboard layouts (e.g., the `à` button on Spanish keyboards, as mentioned by the OP). There exists the possibility that the two input methods generate different versions of the same character, which can cause issues if a user's preferred method is disallowed (e.g., the OP didn't have access to a Spanish keyboard, such as if logging in from a system that only supports QWERTY). – Justin Time - Reinstate Monica Feb 06 '20 at 00:51
  • 3
    @Vilx- To expand Justin's point slightly, the problem with Ctrl/Alt key switching is not that the keyboard can't let you enter accented letters. In your username it's fine, because you can see the letters appear, and if this keyboard needs something different then you can sort it. The problem comes with the password, which almost always has the characters hidden. If you can't cast-iron guarantee that every keyboard in the world will give you the same accented characters from the same Ctrl/Alt keystrokes, then entering your password with accented characters is going to screw you at some point. – Graham Feb 06 '20 at 01:46
  • For a concrete example - albeit a slightly different situation: https://apple.stackexchange.com/questions/202143/i-included-emoji-in-my-password-and-now-i-cant-log-in-to-my-account-on-yosemite – mjt Feb 06 '20 at 12:42
  • When the password creation field accepts those characters why not? All the systems I build nowadays have support for emojis in a password. There is no reason to not do it when it is accepted. – StefanJanssen Feb 06 '20 at 15:33
  • Just wanna point out, python2.7 still hasn't died yet, even if it is no longer supported. (There will even be a 2.7.18 release in april to put the final nail in the coffin.) Unless a 2.7 app was specifically written to use unicode, it's stuck in the dark ages of ascii strings. – Kamilion Feb 07 '20 at 00:05
28

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.

Tom
  • 10,201
  • 19
  • 51
  • 2
    You might enjoy https://github.com/dropbox/zxcvbn – Luc Feb 06 '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 06 '20 at 13:48
  • 2
    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 06 '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 06 '20 at 14:36
  • 1
    @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 06 '20 at 17:32
  • @Tom Since I have no other way of sending you a PM -- that QR code is made to be unscanable right? If yes, the link ends with `42879`. If no, then it needs more jpeg :D – Luc Feb 06 '20 at 18:54
  • I remember one strength checker saying that `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` was a strong password, most likely because of its length. ...It is very possibly the weakest possible 30-character password, due to likely being one of the first permutations that a brute-forcer would attempt. – Justin Time - Reinstate Monica Feb 07 '20 at 03:17
  • @JustinTime-ReinstateMonica you are under the misguided assumption that a brute-forcer would go from a to z. It wouldn't. It would go by frequency of letters in common languages. It would test "e" before "a". Otherwise it's a stupid brute-forcer. – Tom Feb 07 '20 at 10:37
  • @Luc Please do not recommend zxcvbn without mentioning the caveats. For example, zxcvbn considers `a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9` by far a more secure password than `}&wu.y'}rzzQ{n6L2nKgAx?e..Ab'Y~]WeR7}Z[JD7,&&j[ekWB8z*dh`, which we both know is not true. –  Feb 07 '20 at 10:43
  • @MechMK1 Just because it isn't perfect, doesn't make it a bad tool to help the average person (who will really not be hammering the registration page to try and find the weakest considered-to-be-strong password just so he can have a badly protected account). That you can find a loophole is not a caveat. Now, if you could demonstrate that it will recommend someone to use a weak password in a plausible case, I would invite you to add another comment as well as open an issue in their bug tracker. – Luc Feb 07 '20 at 10:49
  • @Luc I remember a case where some really weak password was considered "very strong", because zxcvbn classified it as brute-force rather than dictionary with substitution. I will have to look up the exact password used. My point was that this tool can give a false sense of security on some passwords, and should not exclusively be relied upon. I know this is not what you explicitly said, but a recommendation by a high-rep user can be interpreted that way. –  Feb 07 '20 at 11:46
  • This addresses most of my concerns, it's pretty well written and detailed. However I am not sure about using password managers, that is one great way to lose access to it. E.g. keepass without kbdx file is worth nothing. Also it's not very convenient to open the password manager every single time I want to access something. – Héctor Álvarez Feb 08 '20 at 16:58
  • Fair enough, @Tom. Wasn't entirely sure of the exact logic they use for determining how to attack. – Justin Time - Reinstate Monica Feb 10 '20 at 21:34
  • @Luc that QR code just is a link to my Google Plus profile, which I use to log in here, and which contains nothing else of interest because I used G+ for maybe three weeks before I abandoned it. :-) -- at that time I just found it a cute idea to have a self-referential profile picture that essentially loops back to itself. – Tom Feb 11 '20 at 11:09
  • @tom Oh, because it's super blurry and I need to enhance it to a certain setting before the scanner even recognizes the corner markers. But okay, if it works for you :P – Luc Feb 11 '20 at 12:19
  • I've noticed that if you use A LOT of very few special characters, For example, a 24-length password with 25% of it containing just `!`, it produces passwords that are weaker than if alphanumeric with just 3-4 instances of `!`. Basically I found the best results are if special characters make up only 15%, numbers make 30% and aLpHa 55%. – bryc May 20 '21 at 00:29
  • @bryc one reason I strongly advise AGAINST special characters and numbers is that they actually REDUCE the search space. If I know your password must contain one number and one special character, then those two characters have only about 10 possible characters, not 26. (if you think more than 10 or so special characters are in the set that average people would use, you're deluding yourself) – Tom Sep 09 '21 at 14:06
7

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

abcdef

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.

Konrad Borowski
  • 173
  • 7
5

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.

jamesdlin
  • 2,055
  • 1
  • 12
  • 13
3

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.

PDP11
  • 31
  • 2
2

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.

paradx
  • 21
  • 3
2

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.

Michael
  • 2,432
  • 2
  • 20
  • 37
Ray
  • 231
  • 2
  • 5
0

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:

   Th1s$ecuritySucks!
   Th2s#ecuritySucks!
   Th3s@ecuritySucks!

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.

HumanJHawkins
  • 121
  • 7
  • "*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 06 '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 06 '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 06 '20 at 17:53
0

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.

Walter Tross
  • 101
  • 4
-1

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.

Overmind
  • 8,829
  • 3
  • 19
  • 28
  • 1
    I specifically said extended ASCII, which is up to 255. – Overmind Feb 06 '20 at 09:20
  • Added extended. I used 0-255 anyway, to be clear. – Overmind Feb 06 '20 at 11:40
  • 1
    You will have much fun trying this in different locales or non-Windows machines ;-) – René Feb 06 '20 at 12:53
  • This makes no sense at all. Since it's too much to write in a comment: https://pastebin.com/f4HTpdnX – Luc Feb 06 '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 07 '20 at 04:01
  • I did not state that there is a difference in entropy. Your math is good, but password crackers will very unlikely search for characters as the ones I listed compared to UTF-8s. – Overmind Feb 07 '20 at 06:09
-1

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.

Émile Jetzer
  • 119
  • 1
  • 1
  • 5