Will "☺ ¹²³ µ‼µ ÚÛÙ ♥♦♣♠" work as a password?

Question

Will "☺ ¹²³ µ‼µ ÚÛÙ ♥♦♣♠" work as a password? If so, can you give me a password cracker specifically designed to crack non-keyboard characters? If yes, do you think it will crack this one?

Answer 1

In theory, it should work. Practically, as others have said, there may be issues.

NIST 800-63c says unicode characters should be normalized before they are hashed, and that users should be warned "that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully".

Answer 2

Yes and no.

While there is merit to this obfuscation method, it's not magic and you need to be highly concerned with portability. At the end of the day, all that matters is complexity. How many characters you use to accomplish this is not terribly relevant.

I have noted in the past that this is a good idea, saying "a password of ••••••••• (nine bullet characters) is embarrassingly secure (and looks the same masked as unmasked!) due to length and obscurity, though it'd be a horrible idea to actually depend on just this fact."

Portability is a big concern with your proposal. Even in an non-cloud system, you risk software updates changing how characters are interpreted and a bugfix might end up changing how your password is decoded (including normalization issues). I wouldn't be comfortable with this trick unless there was another way in (a security key or perhaps a password reset feature).

You should use a password manager instead. Have it generate very long codes (20 characters of all available types, or else as long and complex as the target system allows) rather than trying to design your own system, with the only exception being passwords you cannot rely on your manager for (the code for the password manager and the code to unlock your computer to then gain access to the password manager).

For passwords you actually need to memorize and enter manually, my advice is to generate a 6+ random word code and add a classic password somewhere in the middle.

If you want to use an emoji or other extended character, be careful not to complete a concept (piña colada horse battery staple is basically a four-word phrase while correct ñ horse battery staple is harder to break). Add or upgrade, don't replace. sQD4{ horse battery staple is better still, and sQ☺4{ horse battery staple further improves your strength (again, at the potential cost of portability).

Your attacker's best-case scenario would be to know exactly where your non-keyboard character is and what your password scheme is (e.g. "one word, an emoji, then five words"), which puts the entropy at log₂(100000×4000×100000⁵) = 111 or, with 7 Diceware words, log₂(7776⁷×1000) = 102. (This uses a very broad definition of "emoji"; Emojipedia generously counts 3,664 but a more realistic number would be 2000.)

As you've surmised, your attacker's worst-case scenario is that they'll never even try a code with your mystery character(s). However, you must assume your attacker knows your system, so don't dwell on this too long. It may seem clever, but the professionals know all the tricks and employ impressive password-cracking clusters.

---

Let's calculate the entropy of your ☺ ¹²³ µ‼µ ÚÛÙ ♥♦♣♠ password. Its raw bytes via a hex dump:

$ printf %s '☺ ¹²³ µ‼µ ÚÛÙ ♥♦♣♠' |hd
00000000  e2 98 ba 20 c2 b9 c2 b2  c2 b3 20 c2 b5 e2 80 bc  |... ...... .....|
00000010  c2 b5 20 c3 9a c3 9b c3  99 20 e2 99 a5 e2 99 a6  |.. ...... ......|
00000020  e2 99 a3 e2 99 a0                                 |......|

That's 38 bytes of content. If we're to assume it's randomly selected from Unicode (and it's very clearly not), we could very roughly approximate the entropy as log₂(256³⁸) = 304 (which is impressively high). However, Unicode isn't that straightforward and you simply chose some characters to illustrate your point. Your password's actual entropy is closer to 70.

I like counting in equivalent random keyboard characters (which I count as 94). Generally, a random emoji is worth 1.6 random keyboard characters (log₂(2000) ≈ log₂(94¹·⁶)) and a random dictionary word is worth 2.5 (log₂(10,000) ≈ log₂(94²·⁵)) while a random Diceware word is worth 2 (log₂(7776) ≈ log₂(94²)). See also the password entropy table I created to explain this math.

Accented letters beyond languages you're associated with (that you or your friends/family speak or that exist on your computer) can count as 256 in these calculations, a small upgrade atop a random keyboard character (1.2 characters to be exact). I'd count emojis as 2000 (1.6c) unless you use them in everyday life, in which I'd count them as 32 (0.7c), just like keyboard punctuation.

Answer 3

I would like to add a couple of additional points to Adam Katz's outstanding answer.

Unicode normalization

The Unicode normalization issue is not merely a theoretical problem. The specification in NIST-800-63c about unicode normalization is in there as a result bitter experience. For example the character Å does not have a unique byte sequence. And password hashing has done by the service is going to operate on the sequence of bytes it receives. Unless it takes special measures, it will not recognize different a different byte representation as the same password.

All versions of 1Password (my former employer) accepted UTF8 Unicode encoding for master passwords, but only in around 2015 did it start to normalize them. (Transitioning had to be managed very carefully). Before normalization people could find themselves locked out of their 1Password data merely due to changing their physical keyboard or even an operating system update.

So unless you know that the application or service that will be processing your password has committed to a normalization scheme to address this problem, do not use such passwords.

The Kantian Principle

At the moment, so few people use non-ASCII characters in their passwords that most password cracking systems don't bother searching those when they have a bunch of different hashes to crack. They all can do such things, but going after such things is not considered a good use of effort.

But that will change if people creating passwords change their behavior. The people doing the cracking pay extremely close attention to optimizing their cracking efforts based on the patterns they see in leaked passwords. And because they have access to more compromised passwords than researchers do, they have the best understanding how people create passwords. So using a rare password composition scheme will only work temporarily.

This is why I offer what I call the Kantian Principle of Password Creation Schemes.

Use only those passwords creation schemes that remain strong if everyone used the same scheme.

Expanded alphabet doesn't always mean stronger passwords

If people were as likely to pick, say, the 𒀝 grapheme (Hittite cuneiform for "ag" syllable) as they were to pick the 💩 (poop emoji) then the enormous number of possible graphemes mater. But people don't behave that way. Experiments which asked people to construct passwords with emoji resulted in lots of poop.

All of the fancy calculations that people like to do on those sorts of things assume that people pick passwords with a uniform distribution. All evidence is exactly the opposite. The people who crack passwords know this. They don't blindly search the whole password space.

Use a good password generator

The only thing that will pick uniformly is either a scheme that involves something like rolling dice or uses a good random number generator. A 23 character password made up only of letters is already going to exceed 128 bits if the letters are picked through a uniform random process. You probably need to ensure some digits and symbols to meet other requirements, but you can easily get all the strength you need.

The good thing about this scheme (using a good password generator) is that it remains just as strong even when the scheme is fully known to the attacker. It fully satisfies the Kantian Principle.

Answer 4

If the application or system handles those characters then then it should work (as do passwords containing other unusual characters like emoji) - although if they're not handling non-ascii characters properly then you can sometimes run into problems. You can also run into length-realted issues where developers make the dangerous (and often incorrect) assumption that 1 characters = 1 byte, especially with algorithms like bcrypt.

It can certainly bring security benefits to use characters that aren't part of the standard ASCII set (including accented characters, or symbols like £ that aren't on a US keyboard), as many of the wordlists and rules that people use are rather US-centric. But it can also cause problems - I've run into things like SSH clients that failed to login if the password contained a £, and if you ever have to login with a different keyboard layout it can be tricky.

But decent password cracking tools will support non-ASCII characters, so that kind of password can potentially be cracked depending on the specific wordlist and rules that are being used.

Answer 5

In an application, there are multiple components involved in processing a password. Whether or not a particular password is supported depends on all of those components.

• Password hash algorithms deal with bytes, not characters. Modern algorithms like Argon2 accept arbitrary bytes, so it doesn't matter what the password looks like and how it is encoded. The input could also be a sequence of arbitrary bytes that don't have a meaning at all. Legacy algorithms like bcrypt have more restrictions. For example, the input is limited to 72 bytes, and the reference OpenBSD implementation doesn't support null bytes (because those are used to terminate strings in C). Your particular example is fine.
• The application frontend may or may not support your password. This depends on which character encoding the text field for the password uses. If it's ASCII, you're limited to the 128 characters of the ASCII character set. If it's UTF-8, you can use any Unicode character.
• The same is true for the backend. Some backends can only handle ASCII characters, some accept arbitrary Unicode characters, others are restricted to a subset of Unicode (like the Basic Multilingual Plane).
• In addition, applications can (and often do) impose arbitrary limitations on the password. For example, you may only be allowed to use alphanumeric and a few special characters, even if the application could technically support much more complex passwords.

In general, non-ASCII passwords are not recommended, because applications may be unable to handle them correctly, and they do not increase security. For security, the only thing that matters is the entropy of the password, measured in bits. To get 128 bits of entropy (which will lead to a very strong password), you can generate 16 random bytes. How you then turn those bytes into characters is -- from a security perspective -- completely irrelevant. If you use 7-bit ASCII characters, then you need 19 characters, because 19 * 7 bits = 133 bits (18 characters wouldn't be enough, since 18 * 7 = 126). Alternatively, you could use Base64 or even restrict yourself to alphanumeric characters. Of course the smaller the set of possible symbols is, the longer the password has to be.

As to password crackers, any halfway modern tool will support non-ASCII characters. hashcat does, John the Ripper as well. Since there are languages which don't use the latin alphabet, it would be absurd to only allow ASCII.

Answer 6

Will "☺ ¹²³ µ‼µ ÚÛÙ ♥♦♣♠" work as a password?

In theory, yes. But some applications do not handle well Unicode/emojis characters internally.

But if you reuse the same password elsewhere and it leaks to some pwnlist somewhere, then it would become a risk. It would be no better than any other leaked password.

If the point is to make a password that is unpredictable, then this is overkill. You could just stick to a more practical password, that is long enough, and preferably not used elsewhere.

I may be wrong, but I doubt that your keyboard does allow you to type this password in a convenient manner. Producing the accented letters may require a keyboard combination. Probably you will have to write it down somewhere in a file, or keep it in a password manager. Then you should just let the password manager build a random password for you.

If so, can you give me a password cracker specifically designed to crack non-keyboard characters? If yes, do you think it will crack this one?

A password cracker can be tuned to use a specific character set, even certain patterns. If I were to conduct a targeted attack against you, and I know you use such patterns (or variations), then I would definitely tune the cracking accordingly.

When the attack is untargeted and there is no knowledge about the victim, then you resort to brute-force and word lists. This password would very likely withstand brute-force, because most people (at least in Western countries) are usually going to stick to alnum + a couple "special" characters like underscore. But there are so many passwords that are less elaborate and equally secure.

The proposed password has in fact repetition and poor entropy. So it's more a novelty than superior security.

Answer 7

Firstly, please see: Can using emojis make someone's password safer? because this question is very much related to emojis in passwords.

I’d think systems would receive the emoji as UTF-8 (0xF0, 0x9F, 0x92, 0xB0,) so that they could be hashed and/or encrypted.

So yes, adding emojis would add a few extra characters per emoji, making a password much stronger depending on how many you put in.

In terms of giving you a password cracker- like Schroeder mentioned- just use a popular one- and what do you actually mean by this- as in what password hash are you trying to ‘crack?’

I primarily use Hashcat, and because the first bit of answer has been quite similar to the other answers, I’ve tried to come up with some kind of time cracking estimate with different scenarios such as hash type, mask knowledge, my hardware, etc.

Let’s say that you have a relatively weak MD5 hash at your hands, and my sole processors to use, and I know absolutely nothing about your password- not the length nothing- by the time I got to trying your password length with a complete character set- it’d just be completely useless- several thousands and thousands, perhaps even millions of years for one sole computer.

But now let’s say I knew the approximate length and the approximate amount of emojis you put in, I could make as part of a hybrid brute force, utilise Hashcat to include 0xF9, 0xF8 and so on for every emoji.

This would vastly limit the number of guesses that would have to made in order to crack your password. I’d say then it would take Hashcat more like a few years for one computer, so very achievable for a botnet or super computer.

As I’ve said, this is only for the (relatively) measly MD5 hash, and not more complicated ones.

Now to answer your question:

do you think it will crack this one?

No idea.

Is it likely that an attacker will crack it?

I’d say no.

This also depends on how much value the attacker would gain by obtaining the plain text password, and how much they would have to spend.

Would this be a good, secure password for classified military documents? No, of course not!

For you? I’d say it’s quite safe.

Answer 8

Full Unicode including non-trivial characters is problematic.

As defined by Unicode, there is a large number of byte sequences that are defined to be the same. Take the made-up character “capital O with umlaut and cedilla” this could be Ö + modifier cedilla, O + modifier umlaut + modifier cedilla, or O + modifier cedilla + modifier umlaut.

All three should be treated as equal everywhere, including in passwords. So all three need to be translated to the same bytesequence. And that must be true wherever the password is entered. Like on iOS, android, macOS, windows, Linux and with any browser. And that is a problem.