Do non-keyboard characters make my password less susceptible to brute forcing?

Question

I can put characters in my password for which there are no keys on a keyboard. On Windows, Alt+#### (with the numpad) inserts the character for whatever code you type in.

When I put this in a password, does it pretty much guarantee that it will never be brute forced? I'm probably not the first to think of this, but am I right in guessing that attackers will never consider it worth their time to check non-keyboard characters? Is this even something they are aware of?

If that is the case, with a single non-keyboard character somewhere in your password you'd never have to worry about keeping the rest of the password strong.

Answer 1

When I put this in a password, does it pretty much guarantee that it will never be brute forced?

A brute force attack on a password tends to happen one of two ways: either an attacker obtains a hashed password database, or an attacker attempts to login to a live system with a username (or other account identifier) and password. A common method of attacking hashed password databases is to use a precomputed set of values and hashes called a rainbow table. See What are rainbow tables and how are they used? A rainbow table is not a pure brute force attack because it uses less than the full domain of possible inputs. Since a true brute force uses attack every possible input, regardless of whether it is an attack on a hashed password database or a live system login, no character set selection or combination of different sets will make any difference to a brute force attack. Practically true brute force attacks are rare. Rainbow table attacks are more common, and using a value from a uncommon set will be an effective defense against many rainbow table attacks.

am I right in guessing that attackers will never consider it worth their time to check non-keyboard characters? Is this even something they are aware of?

There are attackers out there who will use uncommon input sets to try and attack passwords, but I suspect they are rare. Any reasonably sophisticate attacker has thought about things like non-keyboard characters, and most make an economic decision to go after the easier targets. There are plenty of targets with poor and weak passwords, so attackers design attacks for these weak passwords. So, yes, many (but not all) attackers consider strong passwords not 'worth their time'.

with a single non-keyboard character somewhere in your password you'd never have to worry about keeping the rest of the password strong.

No. Strength is a measure or resistance to attacks. If your password is a single non-keyboard character it is weaker than a password of 33 lower case characters. The length in bits is an important measure of password strength. Bits instead of characters, because cryptographic computations like hashes are done in bits, not in characters. A character set, like the set of non-keyboard characters, is only one element in making strong passwords, it is not strong by itself.

Answer 2

So because I had to know I generated an NTLM rainbow table using the non print character alt 0160 (and non-keyboard represented)0161-0164. The table recognized the non-print character in hex.

The table was able to recognize the non-print character after dumping the hash. (It was a dummy account with a 4 character password for demonstration purposes)

It comes out looking something like:

So although it's not impossible, I didn't have anything in my toolkit that was going to recognize this. Most people with rainbow tables kicking around are either from the community source or have a specific reason for creating them.

I've rarely seen people using these characters, But it makes perfect sense to create a few more tables to include depending on the engagement: £ ¥ ¡ and a few other punctuation marks that are only used in non english languages. Looking on keyboards around the globe for the most common and looking for characters that aren't represented in the US-104 is going to give me a good start. But again, this tableset when made is based on 1 thing: common use. If it's not commonly done, then it probably is easier to find another way to bypass the control.

To speak to a straight up input based brute force, the same thing applies. Anyone that includes it in the character set for input could do it. It just isn't normal to do so.

So in a roundabout sorta way what I'm saying is yes it does make it less susceptible to brute forcing, though not impossible.

-- Edit --

For some real number perspective on table generation:

The basic character set I've got piled up for NTLM fits in a 750Gb drive the numbers I've got on it if I wanted to make a new one: (upper+lower+number+print characters = roughly 96 characters)
Generation time 9 d 22 h (if too high increase number of tables)
Unique chain count 6,094,373,862
Table size 90.81 GiB (97,509,981,789 Bytes)
Total size 726.51 GiB (780,079,854,310 Bytes)

Now this isn't optimal, but for comparison sake the same settings (actually a little kinder settings 8 tables instead of 4 using rtc ) on the full print + non print + non-keyboard ascii set (191 characters) equates to (with compression)
Generation time 395 y (if too high increase number of tables)
Unique chain count 4,823,766,839,375
Table size 57.03 TiB (62,708,968,911,909 Bytes)
Total size 14.20 PiB (15,990,787,072,536,668 Bytes

Essentially 2 orders of magnitude more if you're using the whole ascii character space windows will accept as password input. I'll have to wait a while for that 20 petabyte Seagate before starting down the road to this table. And processors need to speed up if I want the table to finish before 8 generations of me have lived and died.

Answer 3

An attacker only needs to expand the character set he uses to bruteforce any password, no matter what characters are in it. That said, the bigger that set the more time he needs to spend.

The usual recommendation is that if you throw in small letters, caps, numbers and symbols, all in ascii, the character set you are using is big enough to hinder bruteforcing sufficiently. If you go beyond the ascii set, you can also look at greek or russian characters - the non-printable and random unicode thing is a bit too far in my opinion.

You can do it of course, but there is a risk: else: Not all apps, and especially sites and databases are compatible with UTF encoding, or things different than iso-8859-1. This means that your password might not be accepted by an app/site, or even worse, be accepted but get messed-up in the way to the database, so that you wouldn't be able to verify it. Unfortunately all kinds of weirdness can happen when you provide non-ascii input to an app that's not expecting it, especially on username and password fields.

Answer 4

Using Alt+#### (four digits) is equivalent (for resistance to attacks) to having the four digits as password characters, right where you add your "special character". Digits in passwords are not a totally new thing.

"Attackers will never consider it" is the basis for all weaknesses. Attackers will consider it; they even thought about it before you. If you rely on attackers' stupidity then you will defeat only stupid attackers -- the ones which are the least dangerous in any case.

On a more practical note, special characters will make your life harder when you try to use a device which does not offer Alt-based character entry (e.g. a password on a Web site, that you wish to access from your smartphone).

Answer 5

As has been said in other answers, the strength of the password lies in its size. You could press the keys Alt+0+1+6+0 to get an uncommon character, but then you're only getting 1 character out of 5 keystrokes. Taking this as a rough estimate, you may be getting some 12, maybe 13 bits of entropy out of a special character; you could have gotten more (above 20) if you used those 5 keystrokes on alphanumeric characters.

In short, it's more useful to use 5 on-keyboard characters instead - you're getting much more buck for bang, if you pardon the pun.

Answer 6

Assuming solid UTF-8 support (thus eliminating other encoding issues), a potential pitfall of non-ASCII passwords is Unicode normalisation.

Characters like ö can be represented in multiple ways, i.e. as a single ö character or as two codepoints: o+¨

Generally, computers don't consider these equal, even though they really are.

As a result, a naïve implementation that doesn't normalise password input before verification may not accept the password pässwørd if you manage to enter it in a differently-normalised form to when you set the password.

Answer 7

If the security is based only on a belief/assumption that an attacker will not use technique X, this is pretty weak security. It should be assumed that an attacker knows it.

Like in chess, make the strongest move as if your opponent knows your intentions.

Answer 8

While extending the character set used in your password makes it stronger, it also makes it hard to type and doesn't provide 100% garantee against attacks.

More importantly, using rare characters exposes you to situations where you know the password but cannot use it. Imagine not being able to use a recovery tool because it is not compatible with your password, or not being able to check your mailbox from someone else's computer or smartphone.

Answer 9

In summation: against a Dictionary/Rainbow style attack they tend to be VERY secure because a single untypeable character will drop you well out of any common schemas, but against a true brute force attack they can be a lot weaker than using your 2-5 other keystrokes in a normal fashion. So, the optimal strategy in my opinion is to combine them. Make your password too many characters to be discovered by a true brute force attack in any reasonable human timeframe, and include an Alt-% character to drop the "popularity" of your password beyond what is considered a worthwhile educated guess. This can make your password effectively as secure as a truly randomly generated string, but easier to remember. Just make sure the random character you use is not something likely to hold meaning in any programming language or foreign keyboard set such as those funny characters really low on the alt-table: ☺, ☻, ♥, ♦, ♣, ♠, ◘, ↕, etc.