> For sites that disable pasting,

For Firefox, setting the "dom.event.clipboardevents.enabled" about:config option to false prevents clipboard paste events from reaching javascript. No more blocked pasting after you toggle that option, even if the website attempts to do so.

I've seen sites that disable the input whenever the ctrl key is held down.

Use "Paste" from right click menu. Configure your environment to use a different paste keyboard combo. Use the old X11 clipboard with middle button paste.

Came here to say this, this should be the top post.

Use KeePass's auto-type feature. I'm not familiar with other password managers, but for KeePass it emulates a keyboard, and works on sites that disable pasting.

Wow, I've been using KeePass like a monkey then, thanks for this.

I just had the joy of entering in a PM generated 64 character password into a new Android phone during the set up process; fun!

If you can remember it that means you need to change it! I refuse to look at any of my generated passwords. For the services that wont let me paste in, I have a macro that will type whats on my clipboard. Just a simple auto IT script with a WAIT (so I can make sure I focus on the input box) and SEND.

My password manager also clears the clipboard if it is equal to the last password copied after a wile (I've never timed it).

> If you can remember it that means you need to change it! I refuse to look at any of my generated passwords.

I'm trying to understand the reasoning for this. Are you dealing with very sensitive information that you have a real reason to fear the rubber-hose cryptanalysis method?

More because you'll develop a resistance to changing the password, since you'll have to start over on memorizing the new one.

AFAIK the benefit of changing passwords regularly is highly debatable anyway. If so, I think "Don't change it, since you would have to memorize the new one" is more logical advice.

This is a good point, and part of the problem with the way the average computer user (and far too many above-average users) treat their passwords.

As a consultant, I have been given access to a lot of passwords for clients. From corporate bank accounts to production servers at government agencies. So they are very sensitive, and when my contract is up, I delete the password folder for that client. I started doing that with clients, then eventually ended up continuing it to my personal passwords as well.

You talked about not even looking at generated passwords, which is different from client's passwords. That's the part I didn't understand.

Although, honestly, the other part seems more bizarre. Gov't agencies and other clients are just giving you their sensitive passwords, and trusting you to delete them after the project, at your leisure? How is that not terrible security? Revoking a consultant's security needs to be in the hands of the employers.

I'm pretty sure the passwords I'm given are generated. I wouldn't really know as they shared the passwords in a file with me that I never looked at them. I'm sure they cleaned up accounts on their end, but I would rather do some due diligence on my end as well. I don't know their processes and procedures.

But why even know your own passwords, what is the point? If I can double click from my manager and paste it into my password field and never have to worry about knowing anything, I'm much happier and safer.

For those not familiar with the rubber-hose method: https://xkcd.com/538/

Personally, I always thought the phrase ought to be "brutish-force cracking," like "brute force", but that's just me...

Sometimes I open the developer tools and paste the password in the value of the input element there. It usually works.

I write an Alfred (https://www.alfredapp.com) workflow that sends keystroke events using AppleScript for arbitrary strings, specifically to work around SPP.

The AppleScript in question is very simple, it just looks like

  on alfred_script(q)
      tell application "System Events" to keystroke q
  end alfred_script