Why can't we use/set function keys as password keys?

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?

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 26⁸ = 208827064576 combinations. Expanding it to letters and numbers would give 36⁸ combinations, 13.5x more. But if you instead just made it one letter longer, you'd get 26⁹ possible passwords, exactly 26x more. Two letters longer? 26¹⁰ 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...

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.

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:

• Where to learn more about OSX terminal app keyboard settings codes?

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:

• How does the Windows “Secure Desktop” mode work?
• Sending fake keypress events to an X11 window