In any operating system the passwords with Fn were not allowed. For instance, I can't keep Fn + some character as password.

What's the reason behind it? Any technical aspect which prevents the operating system designers from allowing Fn keys as passwords?

A reason I can think of is that in some laptops the Fn keys will enable or disable the number keypad. But what about desktops? As desktop keyboards have separate Fn, why can't we use it in passwords?

  • 1
    What OS are you talking about? Windows, linux, mac? – LPChip Dec 2 '15 at 11:28
  • 2
    I am not sure I have ever seen a keyboard with an fn key. Surely this itself is a motivator if it means many keyboards cannot type this password at all. – Vality Dec 2 '15 at 12:00
  • 1
    @Vality: laptop keyboards use them (e.g. my netbook is too small for a number pad, by pressing [Fn] I can use a block of letter keys (and 7,8,9 from the number row). [Home] and [End] are only accessed using [Fn] but they couldn't be characters in passwords. – Chris H Dec 2 '15 at 12:10
  • 2
    The behaviour on Ubuntu (14.04)'s login screen is interesting, and may give a clue as to some underlying reasons: I can enable the numpad using Fn+Numlock (normal for this keyboard) and then use the number keys successfully (it's not giving much away to admit that my password has digits in). With [Fn] + the same keys (recognised as numbers on win7) the keys act as arrow keys (plus Home, End...). This isn't expected behaviour. Maybe a combination of not loading the user's keyboard settings when they're not logged in, and a high potential for confusion makes it not worth implementing. – Chris H Dec 2 '15 at 12:13
  • 24
    lol. fn keys are hardware specific. they're not even os specific. next you'll want to use the power, reset and brightness keys in your password – Mark Ch Dec 2 '15 at 18:07

Passwords are nothing more but text; they contain characters, not keypresses. Computers aren't like mechanical typewriters, and there is a distinction between these two.

Using recorded keypresses for passwords would give nothing but disadvantages:

  • Security: Making the password longer can be more efficient security-wise than increasing the alphabet. (If you start with basic 26 letters, a 8-letter password has 268 = 208827064576 combinations. Expanding it to letters and numbers would give 368 combinations, 13.5x more. But if you instead just made it one letter longer, you'd get 269 possible passwords, exactly 26x more. Two letters longer? 2610 possibilities, 676 times as many. I'm on a horse.)

    (Although on the other hand, simple calculations like that don't account for dictionary attacks, but I don't think the same people who use their name as a password would voluntarily do a function-key dance if it were possible.)

  • User expectations: Almost everyone thinks of a password as something containing words and letters (just kept secret). So if a key like F7 or Fn doesn't type a character normally, then it shouldn't type anything in password fields either. If it does something like resize the window or pop up Google, it should do exactly the same in password fields as well.

  • Primary purpose of the function keys: Some keys are used by the program itself, or by the operating system. Which keys are used varies between systems. Sometimes new keyboard shortcuts are added.

    Let's say you used WinI in your password, then upgraded from Windows 98 to Windows 10; now you can't type your password anymore because WinI is used by the OS itself.

    Or maybe you used FnRight with your old laptop, but it means "skip to next song" on your new one. Suddenly you can't log in to Gmail unless you close the music player first.

  • Variation between devices: Some keys don't exist in all keyboards. When was the last time you saw a PC desktop keyboard with a Fn key? Or a Mac keyboard with the Win key? Even the same PCs don't always have Pause or SysRq anymore.

    How would you enter these keypresses on a mobile device? Let's say on a feature phone with 12 buttons? Or an iPhone, before they started allowing third-party keyboards...

    People already have such problems. Often, they cannot even type their own script/language (even basic Latin-with-accents like á or ū) and are forced to stick to what the US QWERTY keyboard layout offers – that's the only thing that consistently works in public libraries and generally everywhere.

  • Finally, the passwords remain text (and many OS components expect them to be text), so the OS would need to decide how to translate each keypress to something that can be stored as text.

    xterm-like terminal apps already do this (as did actual physical terminals) – and yet, after three decades, they still haven't agreed on one way to do it. There are at least two different translations for arrow keys, and at least four different ways to translate F1-F12.

    So you can input F3 and terminal-based programs will see it as text – but you don't know whether it will be ESC O R or ESC [ 1 3 ~ or ESC [ [ C or ESC [ O...

  • 1
    I just tested, and F3 translates as ESC O R for me, not ESC O Q; I think you might have an off-by-one error ;) – IMSoP Dec 2 '15 at 12:30
  • 10
    I'm most interested in the example where someone upgrades from Win98 to Win10. – Engineer Toast Dec 2 '15 at 17:06
  • 10
    @EngineerToast: Chain of fools? You just have to temporarily downgrade to ME, then upgrade to 2000 and XP, then downgrade to Vista, upgrade to Win7, downgrade to 8, upgrade to 8.1, etc. – grawity Dec 2 '15 at 18:45
  • Especially the "variation between devices" part is why, even with a password manager, I limit my passwords to purely alphanumeric and compensate with length where possible. If I ever need to enter a password manually (as I had to do today), I won't struggle excessively, especially on a mobile device. – Nzall Dec 2 '15 at 19:06
  • @grawity Pretty sure an upper end Win 98 machine couldn't support Win 10. The only really viable way I can think of is, "use Win 98 from 99 to 2015, buy new computer in 2015." – jpmc26 Dec 3 '15 at 22:52

Linux will take pretty much any keypress (except modifier keys by themselves) as input for passwords. On my arch system, I can easily set F12-F10-F9 as my password. F11 is missing in that row, because my window manager swallows that key and interprets it as the "fullscreen" command.

That's the issue with most stuff you probably tried: the window manager (GUI) will swallow certain keys before passing your input on to the program you're trying to enter data in. If you are in a console without any GUI on top of it, you'll be able to use pretty much anything you can imagine as password input.

EDIT: also note that some keyboards have their fn-key inputs hard-wired to hardware changes. For example, on my Lenovo fn+space will toggle the keyboard backlight completely independent of the OS. The OS doesn't even receive the keypress in this case.

EDIT EDIT: grawity's answer (ad the comments on this answer) goes into detail about why you probably don't want to do this.

  • 8
    Note that your password doesn't actually consist of F12-F10-F9; if you know what ASCII sequence it has been encoded as, you could type (or paste) that instead. The one control code (i.e. non-printable character) you are actually saving to the password is likely to be ESC (ASCII 27), indicating the start of an escape sequence. – IMSoP Dec 2 '15 at 12:24
  • @IMSoP Yup, this is covered very well Grawity's answer. – Simon Dec 2 '15 at 12:33
  • 3
    Doing this will bite you whenever there is a change in your environment that causes different text to be generated by the same function key. It could be as minor as a locale change, a remote X session, or a desktop environment upgrade, and you'll be unable to log on. – Kilian Foth Dec 2 '15 at 13:26
  • 1
    Incidentally I got a backspace in my password. That was a pain. – Joshua Dec 3 '15 at 20:23

That's dependent on the terminal, not the operating system.

Some terminals can be configured to store arbitrary strings; I did this for wyse-50's a while back, using escape sequences to program them.

More recently, you can set the translations resource in xterm to send a string. There is no escape sequence for this (which you would find useful: DECUDK is the closest, and sends its result in hexadecimal).

Some terminals (such as Terminal.app) have a preferences dialog which lets you put arbitrary strings there. Again, no escape sequence, but definitely configurable.

Some (apparently gnome-terminal and konsole) let you do some limited configuration of the keyboard.

Ultimately the answer reduces down to finding

  • if the terminal you are using supports that feature, and
  • if so, how to use it effectively.

Further reading:

This answer deals with passwords in terminals, rather than GUI. In a GUI, the application may not even see a function-key as text. GUIs have different constraints, e.g., (per comment) on Windows, passwords may be prompted in the security desktop, so it wouldn't matter much how the keyboard is setup. In particular, since that runs separated from other processes, you could not use an add-on (such as autohotkey) to store/paste passwords. Other GUIs have their own rules (see XSendEvent for instance), which are not necessarily determined by the operating system, but the runtime libraries.

Further reading:

  • In windows, fn+key is handled the same as media keys. It requires a special way of capturing the key which is something that is not supported on Windows, so the OS really does matter. – LPChip Dec 2 '15 at 11:30
  • On Windows, passwords may be prompted in the security subsystem, so it wouldn't matter much how the keyboard is setup (agreed). – Thomas Dickey Dec 2 '15 at 11:33
  • The Windows "security subsystem" isn't magic. It doesn't hook into the keyboard drivers or anything. If it ever shows a password prompt, that's a regular password prompt. – grawity Dec 2 '15 at 11:39
  • I didn't say it was. Along those lines, much of your answer I find not useful. – Thomas Dickey Dec 2 '15 at 11:41

Simply put, you can't use Fn key combinations in your password because there are no corresponding characters defined for these combinations. The point I want to make it that you shouldn't use non-standard keys when typing your password even if you could. If something goes wrong, you will be in trouble. You will know your password, but will be unable to type it:

  • Your computer dies and you plug your HDD into a different one. You can't boot without HDD password, which you cannot type.
  • You have no access to your computer (e.g. on a trip) and have to check an important e-mail. Good luck locating Fn or F1 on your phone.



Because the function keys perform functions on your computer. They do not constitute the addition of text to the current text context (such contexts including password input). The whole point of the function keys is to perform meta-operations that are distinct from text input.

Besides, they are 100% operating system specific and thus not portable at all. You won't find function key codes in ASCII.

  • Fn keys are not "100% operating system specific". They're roughly 95% hardware specific, and maybe 5% OS specific. Either way, though, ASCII standards do exclude them. – Matthew Najmon Dec 3 '15 at 23:04

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.