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.

  • 4
    Don't forget, the set of characters you have on your keyboard is not the same as the set I have on my keyboard... which is not the same as what Europeans have on their keyboards... and Brits are even more different from everybody else. Still, it's an interesting idea, especially considering that there are characters that are not on any keyboard - there are even "non-printable" characters.
    – AviD
    Jun 18, 2011 at 23:08
  • 14
    Its a cute trick, but don't let it make your overconfident about your overall security. Is your account the only way to access your data? Are there other administrative account on your computer? How is Remote Destop Protocol protected?
    – this.josh
    Jun 19, 2011 at 6:28
  • 2
    @this.josh, I think it's clear this only relates to the strength of the password, and not the overall security. Still, it is a correct caveat, though it applies for most questions here...
    – AviD
    Jun 19, 2011 at 6:57
  • 3
    @jnm2 - if you were a target they wanted, and they thought you used non-keyboard characters, or had already used other chars, then yes. But realistically - you'd need to be a very desirable target, as it's going to increase the time a lot:-)
    – Rory Alsop
    Jun 19, 2011 at 17:42
  • 5
    @jnm2 - they do now ;) Jun 23, 2011 at 16:12

9 Answers 9


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.

  • The elegance of a short concise answer is shown here, well said tj.
    – Ori
    Jun 20, 2011 at 13:31
  • Good answer. Also, @jnm2 wrt strength of character sets vs length (and bruteforcability), see my answer on How reliable is a password strength checker?
    – AviD
    Jun 23, 2011 at 16:20
  • What about ~200,000 characters? Or /1000 for ~2,000, /2 (average time to brute force), /2 again (assume other arbitrary restrictions) = 500-character space? 12 characters in that space have ~244 nonillion permutations. Infeasible much (assuming a random enough char distribution in a string defeats heuristics and forces a brute force)? Or what am I missing? Aug 10, 2017 at 17:56
  • If it helps, I have seen a wide variety of non-keyboard characters in some large password lists, as well as nearly all non-English password lists. Additionally, Hashcat mask attack supports --hex-charset, allowing any attacker to use any hex value for their mask/brute force/markov/etc. attempts. Jan 17, 2018 at 7:25

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.

enter image description here

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:

enter image description here

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.

  • 1
    £ is most definitely used in English, what with it being the symbol for pounds sterling, the currency in, well, England.
    – wbg
    Oct 1, 2016 at 22:36
  • Does this also hold true for characters which typically have no representation on any keyboard, such as U+202E (RTL override) or U+1F34C (  )? Nov 13, 2018 at 19:45

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.

  • 4
    Right on. And the app might change over time - upgrade a library or database or something - and break your password. Many apps already have restrictions on character sets, and e.g. don't allow '=' and other silly restrictions indicating bad programming. It isn't too hard to get a password that is resistant to brute-force now even with plain printable chars, but it does have to be relatively long, as discussed in other questions here.
    – nealmcb
    Jun 19, 2011 at 16:12

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).


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.


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.


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.


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.


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.

  • "Just make sure the random character you use is not something likely to hold meaning in any programming language" There is no modern technical reason to worry about this. Oct 31, 2016 at 18:05
  • It depends on on where you are using this password. For example, a database password might work when you type it into your expected user portal, but then break when you later decide to pass it through a connection string.
    – Jason
    Nov 9, 2016 at 19:41
  • Can you clarify the meaning of "connection string"? Nov 9, 2016 at 20:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .