Never Block Password Managers or The Paste Command in Web Applications

A teal coloured padlock on chain link fence.

The cover image for this post is by Paulius Dragunas

This article was created off of the back of a series of tweets that we recently sent out - which were created after having to sign the entire RJJ staff up for a service which blocks both password managers and the paste command.

It’s worth reading the entire thread as a tl;dr for this blog post. But I’d recommend reading the entire post for the reasons why.

Imagine the Situation

You are hired by a company which specialises in web development and security

The company you work for mandates that you MUST use a password manager

The company policies require you to use a vetted password generator, and that those generated passwords MUST use all characters available, and the maximum characters supported, by the service that you are using

Same company policies require you to use 2FA* where it is supported by the service

*=Two-factor authentication

Those are some of the actual policies that we have in place at RJJ.

Now imagine that you are required to use some external service in order to complete a given task. You consult the internal policies, and they state that you must use:

  • A password manager
  • Generate a password
  • All of the supported characters
    • In this instance, that is:
      • Upper-case
      • Lower-case
      • Numericals
      • Special characters
  • The maximum number of characters supported
    • In this instance, that is 60 characters
    • In this instance, the minimum is 8 characters

So you go ahead and generate a password with 60 characters, store it in your password manager, and have it entered into the user-sign up page. You submit the details, they are accepted, and your account is created. You’re sent an email to confirm your account, and you head to the link provided.

Your account has been successfully confirmed, please log in

So you head to the login page, and instruct your password manager to fill your details in. However you’re unable to log in, because the service blocks password managers.

So you decide to take the longer route, by copying your password out of the password manager then pasting it into the password field.

But that doesn’t work either, because the service blocks the use of the paste command.

Why Did They Do This?

The majority of services which block both password managers and the paste command tend to use the “because security reasons” excuse when they are challenged on this. In fact, Troy Hunt has a fantastic blog post about this called “The “Cobra Effect” that is disabling paste on password fields”. I would definitely recommend reading through his blog post, but the tl;dr is:

blocking password managers and the paste command is a solution to a problem that actually makes the whole thing a lot worse

And this is a point which is backed up by National Cyber Security Centre in a post called Let them paste passwords - a post which can be summed up by it’s subtitle:

Allow your website to accept pasted passwords - it makes your site more secure, not less.

As with the linked Troy Hunt article, I would recommend reading the NCSC article in full, as there are important points which are covered in them both.

Interestingly, and rather helpfully, the NCSC article points out that there is no real basis for stopping users from pasting passwords.

It is a mystery where [stopping password pasting] came from. No one has pointed to a paper, a rule, an RFC (a technical standards document to plan how the Internet should work) or anything else that started it off. If you know of one, let us know using the comments form below. We believe it’s one of those ‘best practice’ ideas that has a common sense instant appeal that may have made sense once. Considering the bigger picture today, it really doesn’t make sense.

They also go into a number of usual justifications used for stopping pasting passwords (something they refer to as “SPP” in the article), including:

  • “Password pasting allows brute force attacks” *
  • “Pasting passwords makes them easier to forget, because you have fewer chances to practise them”
  • “Passwords would hang around in the clipboard”

* something I point out is blatantly incorrect later in the article

Not only do the NCSC discuss these justifications, but they also debunk them in the article.

If you’re not aware of who the NCSC are, here’s a quote from the Wikipedia page on them:

The National Cyber Security Centre (NCSC) is an organisation of the United Kingdom Government that provides advice and support for the public and private sector in how to avoid computer security threats. Based in London, it became operational in October 2016, and its parent organisation is GCHQ.

As such, I’m more likely to trust the advice from the NCSC than from a random service vendor.

As a realistic example, a service which all RJJ employess has to use gave the following reason when asked why the paste command is blocked:

"For security reasons, paste command is disabled"
"For security reasons, paste command is disabled"

This is a completely nothing argument, as pointed out in Troy’s article (linked above). But it’s also an argument for loosening user security, which is something that Troy points out in a later article named It’s not about “supporting password managers”, it’s about not consciously breaking security. The thesis of this article is that by blocking password managers, you’re actually forcing users to use less-secure passwords.

So What Can You Do?

Look back at the situation outlined at the top of this article. If you have to use this service, and you can’t use a password manager or copy-paste then you have two options*:

  • Manually type in a shorter password
  • Copy the password to another application, say notepad, and manually typing it in from there

* as we’ll soon see, there’s a third option

The first option above is out of the question, as the company policies require you to use the maximum number of characters, which leaves you with the second option. So you copy the password out to am instance of notepad (or similar) and manually type it back into the log in page.

Any developer knows that human error is the plague of our industry. It’s why we automate our build and deployment pipelines, and it’s why we don’t do FTP based deployments any more. This is the main thesis behind The Phoenix and Unicorn Projects - I would recommend reading both, by the way - and the source of one of the most expensive bugs in history. This reason I bring this up, is because I can guarantee that you’d either have to reduce your typing speed or face multiple typos when staring down the barrel of typing 60 pseudo-random characters into one window from another.

This increases the barrier to entry for using the service, whilst not necessarily reducing the number of attack vectors that malicious users can take advantage of. You end up with users who are either re-using shorter, insecure, passwords, or users who are unable to use your service without feeling the pain of having to copy-paste out to another window then manually typing it back into the window - which is error prone.

Not to mention that the chances of a user forgetting to close the notepad (or whatever application they used), exposing their password to any one reading the screen over their shoulder, is a real possibility. Which further reduces the security of the user’s details.

The Third Option

This option proves that blocking password managers and the paste command doesn’t actually make the service you are using more secure. As with the rest of the article, I’m assuming that you are using a web service via a web browser.

the following is provided as an example and for education purposes. RJJ accept no responsibility for it’s usage. RJJ does not condone hacking of any kind

The following, completely valid JavaScript, can be entered into the developer tools in order to log into a web service which blocks password managers or the past command:

document.getElementBy('username') = "someValidUsername";
document.getElementBy('password') = "someValidPassword";
document.getElementBy('loginForm').submit();

Where:

  • username is the ID of the username field
  • password is the ID of the password field
  • loginForm is the ID of the log in form

This will work on any website which has a log in form, with the bonus of allowing you to paste the password into the developer tools. I wouldn’t recommend doing this however, as both the username and password will be stored in the browser developer tools command cache - allowing you to press the up arrow to run back through the previous commands entered.

It is worth pointing out that the majority of brute force attacks will take a format similar to the above. The actual JavaScript used will likely be obfuscated, but it will likely be very similar.

One More Option

Assuming that you are using Firefox, you can disable blocking of copy/paste using the following steps:

the following is provided as an example and for education purposes. RJJ accept no responsibility for it’s usage.

  • Enter “about:config” in the URL bar
    • The steps we’re about to take could potentially break your installation of Firefox, so you will likely be prompted to confirm that
  • In the search box enter “dom.event.clipboardevents.enabled”
  • Double click the “dom.event.clipboardevents.enabled” result to swap it’s value from true to false
  • You may need to reload the page which has disabled copy/paste

This may not work on every website with a log in form, and has the potential for breaking your Firefox installation if you do it incorrectly.

In Summary

Blocking a password manager or the paste command doesn’t actually increase the security of your application. In fact, it actually leads to the opposite with users either re-using passwords or using insecure passwords. It also doesn’t block the web browser from automatically filling in input fields - which is a MUCH BIGGER SECURITY ISSUE.

Blocking password managers or the paste command can actually make the attack vectors used by malicious users even larger. Since you’re focussing on blocking user commands, you are likely not going to be looking at the use of JavaScript.

The arguments used by the majority of application vendors (those along the lines of “because security reasons”) are not only nonsense, but they also reduce the security of the application without actually reducing the attack vectors used by malicious actors.

If you are working on an application and are asked to block password managers or the paste command, ask the client why and talk them through why doing so will actually reduce the security of their application or service. And if they’re based in the UK, ask them to check the National Cyber Security Centre recommendations.