Why blocking paste on form fields is bad

I was originally writing another blog post which I will now have to finish later but the recent discussion with @TalkTalkCare has left me little choice, so I wrote this one first instead. I want to address the problem, that a certain untruth doesn’t seem to die no matter how often the topic is brought up on social media. I’m talking about the claim that preventing users from pasting their password to login or register, instead of painstakingly typing it, is considered standard – or even best practice. You might notice by the many comments under such statements, that a lot of people disagree with this.

Unfortunately, the typical response of most companies on social media platforms is to claim that it’s “for security reasons”, “standard practice” or even “best practice”, without explaining which security reasons are meant or what standard they are referring to exactly. A good example is the previously mentioned discussion on twitter, but it’s something that is easily observed – just post a security concern to any companies social media channel and chances are pretty good that you’ll get something like this in return.

img-twitter-talktalk-reason

This is of course very unspecific, but I kind of feel like the person just told me that they don’t know why they are using it, but someone told them that someone else is doing it as well and so it must be standard.

But what are these security reasons exactly? I can think of a few things that might go for the exact opposite, such as being able to use a password manager. Forcing users to type their password usually results in frustration from having to type them and probably mistyping them, which in turn undoubtedly leads to said users changing their password to a much simpler one. Be honest, even if you’re really pro security – who likes to type a 40+ character password by hand each time?

The problem(s)…

Of course changing your incredibly strong password to a simple one introduces more problems.

  • How to remember it? If your password is really simple, it’s insecure but easier to remember. However, chances are that you run into the same problem on other sites as well, which leads to another problem.
  • How to remember multiple, simple passwords? Obviously, just use the same for every site!? I think we’ve been over this enough times, so everyone should know by now that this is even worse. Instead, store it in a password manager like the rest of your logins. But that again leads to another problem.
    • Now I have to open my password manager, look at the password and type it in? That’s just bad UX right there. Password manager are being adopted more and more by users, because they offer an enormous increase in security, without resulting in a similar huge work overhead for the user. Blocking the copy and paste feature, strips users of that advantage and usually results in their choice for the (way) less secure but more convenient option.

So we’ve established that this practice not only negatively impacts security and user experience, but also leads to users potentially dropping password managers and reverting to the old one-password-fits-all method. But let’s look at the benefits, that are gained by blocking pasting on form fields, According to TalkTalkCare, the reason for blocking copy and paste on password fields is, because passwords can easily be extracted from the users content by a simple script.

img-twitter-talktalk-scripts

The simple script

So how exactly does this work? How could someone access another users clipboard content? Well, obviously through installed malware or physical access but it would make users vulnerable to keyloggers, so I don’t think that’s where we find our answer. Any script that is executed on the sites servers or the clients operating system directly, is out of scope as well, since preventing copy/paste on form fields doesn’t really offer any protection to users, once an attacker has made it that far. That leaves us with JavaScript, which I assume is, what @TalkTalkCare meant when they mentioned the “simple script”.

So how exactly can someone access another users clipboard content with JS?

First of all, accessing the users clipboard content strongly depends on the used browser. Firefox for example doesn’t allow it by default and requires manual adjustment in the browsers settings.

simple-firefox-script Source: 1 and 2

This could also be observed by testing an example script from SO in Firefox 40.0.

simple-chrome-script

In Chrome v44.0 on the other hand, the script proved to be successful.

While Internet Explorer 11.0 executed the script fine and presented us with the clipboard content, the new Windows 10 browser “Edge” did not. However, that is not to say that there aren’t any other ways to achieve this.

simple-ie-script

simple-spartan-script

There are other ways to access the clipboard, such as the ZeroClipboard plugin, which utilises JS and a Flash movie but requires user interaction to work.

Executing the script

But even so, before any clipboard content can be read, an attacker would have to find a way to actually use these techniques and get the victim to execute the script. This could be achieved by exploiting an XSS vulnerability, provided that the attacker can find one. To me, all of this seems to be avoidable by making sure that this can’t happen – for example by regularly analysing the sites source code and implementing a restrictive content security policy (CSP). This would not only prevent this attack scenario, but many others that originate from XSS vulnerabilities and would enable users to keep using their password managers at the same time.

Summary

It would seem to me that the value added by blocking the paste function doesn’t really show up in comparison to the security gain achieved through the use of password managers and strong, unique passwords. If you currently block the use of password managers on your site, you might want to reconsider that, as it only hurts you customers and users without giving anything in return.

Software used in testing:

Firefox 40.0 (Kubuntu 15.04)
Chrome 44.0.2403.155 (64-bit) (Kubuntu 15.04)
IE 11.0.10240.16384 (Windows 10)
Edge 20.10240.16384.0 (Windows 10)

Update: 02.09.2015

For more information, examples and infosec madness, I highly recommend @Troyhunt's article on the topic.