713312 - Add "secure" on-screen keyboard for input fields (especially password fields) that can be used on systems with hardware keyboards

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Some sites, in particular banking and e-commerce sites in China, are using ActiveX controls and/or NPAPI plugins that implement anti-keylogger techniques (of various levels of effectiveness). One of the anti-keylogger features is an on-screen keyboard that can be used when the user doesn't trust the physical keyboard.

See https://ibsbjstar.ccb.com.cn/app/V5/CN/STY1/login.jsp. The on-screen keyboard can be activated for the password field by clicking the blue "link" with the keyboard image next to the second field. That keyboard is done using JS.

The main problem with a JS-based on-screen keyboard is that the password characters are accessible to the script, whereas with a normal keyboard entry, the password characters are not accessible to script. This is why I think native on-screen keyboard support is important.

The main problem with a native on-screen keyboard implementation is that it would not necessarily integrate well with the design of the website. I don't know what, if any, security considerations would cause us to limit the styling of the on-screen keyboard.

For ease of implementation, especially with respect to localization, it would may be a good idea to use the operating system's on-screen keyboard support.  To see the native on-screen keyboards:
Windows XP: "Click the Start menu, point to All Programs, point to Accessories, point to Accessibility, and then click On-Screen Keyboard to open On-Screen Keyboard."
Windows Vista/7: Type "On-screen Keyboard" into the start menu's search field.
Mac OS X: http://gigaom.com/apple/mac-101-get-an-onscreen-keyboard-in-osx/

I do not know which, if any, operating systems provide APIs for creating custom, field-specific on-screen keyboards. It may be that there isn't a good way to integrate the operating system's native keyboard into the input control. (I am thinking that a smallish keyboard would pop up under the input field, like the autocomplete lists does.)

Note that an initial implementation that allows only ASCII characters would be acceptable, even for China, based on the on-screen password fields I have seen; apparently, non-English characters are not commonly allowed in passwords even in non-English-speaking countries, at least for banking and e-commerce.

On-screen keyboards are especially important for password fields, but this is also sometimes used for some other non-password input fields, such as account number fields and transaction amount fields.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Brian Smith (:bsmith) from comment #0)
> The main problem with a JS-based on-screen keyboard is that the password
> characters are accessible to the script, whereas with a normal keyboard
> entry, the password characters are not accessible to script. This is why I
> think native on-screen keyboard support is important.

What prevents a page from spoofing our native on-screen keyboard?

Further, do we actually do anything to prevent typing that goes to a password control from being accesed by script?  I don't think we do.  I think it only provides security against snoopers looking over your shoulder.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to David Baron [:dbaron] from comment #1)
> What prevents a page from spoofing our native on-screen keyboard?

This is a very good point.

> Further, do we actually do anything to prevent typing that goes to a
> password control from being accesed by script?  I don't think we do.  I
> think it only provides security against snoopers looking over your shoulder.

It seems I was mistaken about this. Of course, we allow scripts to access the contents of password input fields. This is what lets sites verify that "password" and "confirm password" fields match via Javascript, for example. I guess I confused password fields with file input fields. This explains why some Chinese banks already feel comfortable using pure-HTML5 on-screen keyboards for this. 

So, it may very well be the case that there is not any security benefit from doing this within the Gecko input control. That opens up a lot of possibilities, in particular, creating or finding a great open source pure JS+HTML+CSS on-screen keyboard that we could recommend to these websites. Andreas mentioned that we've already got some code for pure JS+HTML+CSS on-screen keyboards for B2G. We may be able to reuse some of that.

On the other hand, there may be reasons to support the native on-screen keyboard anyway. So, I will leave the bug open.

Comment 3

[Jesse Ruderman]

This bug report doesn't make any sense to me. Why would you not trust your physical keyboard (while still trusting any other part of your device)?

If anything, it should be easier to secure hardware keyboard input, if only against phishing/spoofing.