Don't let them paste passwords...
After months of tweets, emails & articles from eminent figures like Troy Hunt & the NCSC, it's about time I weighed in on the debate surrounding sites which disable a user's ability to paste passwords.
The general consensus amongst many experts, including those mentioned above, is that disabling paste on password fields reduces security; the NCSC went one step further, calling it "completely pointless" and "damaging".
So without further ado, allow me to explain why I believe disabling paste can actually increase security.
Disabling paste facilitates barrier-less 2FA.
Confused? OK, let me explain...
Traditional e-authentication systems monitor what you type (your password, for example). This, by definition, provides 1FA or single-factor authentication; you've demonstrated to the site (or verifier, for those of a NISTy disposition) that you "know" the password.
As we know, passwords can be and are frequently stolen, guessed, intercepted, cracked or bypassed... thus requiring a drive towards 2FA or multi-factor authentication.
For many years, companies have focused on introducing a "possession" factor, allowing you to present something you have (along with something you know) to further prove you are who you're purporting to be. That's great, in theory... but the adoption rate of this type of 2FA is pretty abysmal; with some firms (Google et al) seeing figures of < 5%.
Other firms have opted to use a little-known technique called behavioural biometrics/keystroke dynamics. These systems monitor how you type; the periodicity of your keystrokes, how long you dwell between each key, how often you make mistakes, how long each key is pressed and so on. These metrics can be used, with astonishing & near 100% accuracy, to determine who's typing. This is known as an inherence factor. Here's a more detailed explanation of behavioural profiling.
You could, in theory, give someone your password and they'll be unable to login... simply because their typing pattern differs enormously from your own. Think of it as a signature; something unique to you.
Just how reliable is it?
Back in 2015, myself & Per Thorsheim (@thorsheim) presented our research into behavioural biometrics (and how to defeat it) at Cambridge University.
During this research, we demonstrated the ability to shatter a user's anonymity, even when using proxy servers & Tor.
Just let that sink in for a moment...
Even when a user is actively trying to hide their identity using sophisticated & layered defences, the site is able to identify who they are by how they type. No passwords, no perma-cookies... just typing into a webpage.
Many financial institutions, including 2 UK banks actively use this technology in the fight against fraud. Also, HSBC recently announced the introduction of behavioural biometrics via telephone banking; using just your voice to identify you.
How does disabling paste break behavioural biometrics?
When you paste data into a form, the value reaches the DOM almost immediately (a caveat being the use of scripts which monitor for bubble events and delay/block them).
As you haven't typed anything, the script is unable to verify it's really you... leaving you with just single-factor authentication again. Depending on how the site is designed, it may prevent you from logging in, or increase a fraud indicator which prevents access to certain functions (transferring funds etc)
It's true, there are dozens of increasingly-comical reasons why some developers believe disabling paste increases security.
We'll lose our security certificate if we allow paste
We'll be vulnerable to brute-force attacks
True, but attacks are rarely (if ever) carried out this way.
Bizarre eh! But equally bizarre, are the myths which circulate as to why you should be allowed to paste passwords.
It breaks password managers!
Not one for going with the status quo, I decided to test this widely agreed-upon theory.
Disabling paste doesn't break password managers...
1Password, LastPass, Roboform & Dashlane all work perfectly with paste disabled.
How's that possible if paste is disabled?
They don't use paste, at all.
If you're using a password manager which generates & populates password fields automatically, it won't be using the "paste" event to achieve the desired result, thus disabling it has no effect whatsoever. I admit, testing 4 password managers is hardly comprehensive... but they all face the same constraints (set by the browser) in terms of how they interact with DOM elements and nearly all adopt a similar, tried & tested method of populating the field.
Now it's true, some password managers don't auto-populate fields and have little/no integration with your browser; KeePass is a prime example. In that scenario, you would be unable to copy/paste from KeePass to the password field. You still haven't "broken" the password manager or measurably decreased security... only the user-experience (UX) is affected.
"That's a good enough reason to allow paste then, surely?"
Not really, no.
If we make conscious design decisions affecting only people who use password managers, we're already talking a tiny fraction of your potential user-base. To further limit those decisions to people who only use comparably-antiquated and potentially more risky solutions like KeePass, you're probably in the realms of < 0.1%.
Barrier-less 2FA is exactly that... a zero-barrier, frictionless method of increasing security for all your customers, including those who use password managers.
There are many "completely pointless" reasons to disable paste, but that doesn't mean disabling paste is completely pointless, nor damaging.
That's it folks.