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

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.

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.

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.