To counter this: if you happen to find yourself on the phishing domain facebo0k.com and you end up copying your password into that.. Browser extensions guard for this better than we can.

Yes, password managers are way safer than copy-pasting. You don't want something as sensitive as a password in your clipboard buffer, either.

Gah what then? I use strong passwords but almost all of them flow through my clipboard.

I used to use Keepass with auto-type. I had a hotkey for it, and it would recognize the site based on the browser window title.

That would probably be the best of both, no clipboard, and no browser addons.

Instead of checking the TLS certificate or the domain, you are depending on fak3b00k.com not implementing the same title tag as Facebook?

That's something to think about. But I'm not sure how I would end up on fak3b00k.com unless something changed my bookmark for it, or I really mistyped it but if I did that the URL being different is a dead giveaway.

Some password managers will type the username/password into the browser (through a virtual keyboard I think), not copy-paste them to protect against clipboard attacks. Eg. Keepasssc

There are non-browser-extension password managers that still emulate you typing on your keyboard, rather than going through clipboard.

Personally I use rofi-pass to access GNU pass passwords (so just a hotkey and search for password name)

I'd warmly recommend it (or whatever other client you use for GNU pass) but I'm sure you can find similar functionality for any other decent password manager.

Firefox extension, Passhash NG.

Makes them easy to use, with no saved PW.

I a simple algorithm to generate a password based on the name of the service you are using, interleaved with a constant master password you remember. You can do the same thing with a password-manager password + clipboard, interleaved with a constant master password you remember, which should be even better.

Mine clears the clipboard after 10 seconds.

You do realize that in 10 seconds your computer can achieve a lot of stuffs right?

I don't think a webpage can read clipboard without the user manually pasting.

If there's some malicious desktop program running on your machine at the same time as the password manager then you're probably screwed regardless of whether the password passes through the clipboard - but maybe there's some subtleties I'm missing here.

I've accidentally pasted sensitive passwords enough times that I know the procedure is prone to errors.

If I have to do it, I immediately copy something else right afterwards, to avoid an accidental paste later on.

10 seconds auto-clear (which is configurable) is short enough to prevent me accidentally pasting onto some other site.

Could be better if it auto-cleared after a paste, but not sure how feasible that would be.

For example it could just read all the passwords from the password manager's UI.

Between Keepass, 1passwword, and lastpass I've never seen a password manager that just shows the password without the user explicitly choosing to reveal it

1password has the option to do so and I do it on my home desktop computer. Obviously on mobile devices it would be a bad idea and on those I leave that option in it's default, disabled state :)

The purpose of clearing clipboard is so you don't accidentally paste it into a chat window or something. Not to protect against malicious programs.

Maybe we should take the best of both worlds then: an extension that only knows which domains you have passwords saved for, but not the account or PW. It just serves as a red flag if the domain is suspect.

This is how the Keepass Helper extension has worked for years: putting the domain in the RHS of the titlebar. Then with autotype set to match that you can autotype from the global hotkey. Keepass 2 can even split the credentials between key presses and pasting.

There are other URL in title extensions for most browsers. And they're simple enough you can audit them or write your own.

Password managers aren't nearly intelligent enough to be used without copy and paste for sensitive forms.

One example is how almost every password manager including the built-in one in most browsers will assume that if there's a type="password" field, then the previous sibling field must be the username. Sometimes they'll even pick a field far away in the DOM like your chatbox input to autofill with the username.

So imagine a form like this:

    Amount to transfer: <input type="number">
    From account ID: <input type="text">
    Confirm password: <input type="password">
    <button type="submit">Submit</button>

I found that there's no good hackless way to allow a password manager to autofill the password without touching the other fields with a username or some other quirk like just clearing your inputs. Even a fix like opening a modal with the lone password confirmation field doesn't necessarily fix it in all browser/OS configurations.

Password managers are braindead and browsers don't give you any tools to help.

> One example is how almost every password manager including the built-in one in most browsers will assume that if there's a type="password" field, then the previous sibling field must be the username. Sometimes they'll even pick a field far away in the DOM like your chatbox input to autofill with the username.

Note that this behavior is defined as part of the `autocomplete` standard. https://html.spec.whatwg.org/multipage/form-control-infrastr...

> an input element whose type attribute is in the Text state that is followed by an input element whose type attribute is in the Password state

> New autofill field name: "username"

The intent isn't to pick a field far away in the DOM, though, so any autofill implementation doing that isn't being restrictive enough.

Nice note. One problem is that you are left without options, only hacks, to work around this heavy handed behavior. It wouldn't be so bad if you could opt-out with autocomplete="off".

And even if it did work, a spec is always underspecified even for the password manager who wants to follow it 1:1, so even in a best case scenario, you don't have implementation consensus. For example, you would think password manager heuristics wouldn't look outside the current <form> to assume the username field, but some do on some browsers.

The end result is that if you have a need that isn't the general case, you end up having to trade away UX to cater to software.

> Note that this behavior is defined as part of the `autocomplete` standard.

Yes, but it’s my understanding that Chrome ignores this attribute because some website authors abuse it to disable autofill on the login pages because “security”. I’ve also seen some places disable pasting of a bank’s routing and account numbers because “security”. It’s actually more secure for me to copy-paste those numbers than type them because I can’t make a mistake then!

It’s a tough call because I hate when websites do that, but I also want them to be able to disable it in the right places for security.

Yes, and the point of putting in the standard is so that it's documented how to author your website. Unfortunately, some not insignificant number of UI/UX designers want to push their special flow on users and so we get these incompatibilities.

Hopefully the specs and expectations will evolve to the point that if your site doesn't follow the spec no one will use it. I can certainly imagine Apple/Google/Microsoft/Firefox having a semi-seamless sign up and failing to follow the standard means you plenty of users turn away

The spec is underspecified for basic edge cases, like any spec, and it's very hard to have implementation consensus.

This stuff is supposed to improve the UX. Yet the reality is that even when building basic forms, every website has to test and solve the sort of problems shown in TFA.

How much of the spec does every web developer in the world have to read to know that password managers should or shouldn't try to fill in credit card expiry/cvv in a hidden input? Does the spec even say anything about that? 1Password will ignore a `display: none`, by the way. Can this be quick-fixed by ensuring hidden inputs also have `display: none`? That's something every website trying to consider good autofill UX gets to figure out themselves if they even care.

Unfortunately "just follow the spec" does very little to block off the rabbit holes you'll find if you try to perfect UX on even basic forms, else I might agree with you.

I find that both Bitwarden (personal use) and 1password (work use) do a very good job of filling in login forms.

1Password was one of my test extensions and the one I use every day. It works most of the time because username/password combos are the most common autofill configurations.

So common that most password managers don't consider the case where you want to autofill a password without a matching username field on the page. "Password confirmation" being the classic example.

They just don't handle anything other than the main case very well.

Interesting. The weirdest site I use on a regular basis is Mailgun and it has this scrolling form which isolates entry for email/password/2fa (which, as an aside, I hate) and it gets it right every time. I can't remember any instances of it going wrong, actually.

You can still use something like passmenu[0] bundled with GNU pass, bind it to a hotkey and it fills it in as if you were typing on your keyboard, no clipboard involved.

[0] https://git.zx2c4.com/password-store/tree/contrib/dmenu/READ...

Lastpass used to have an option for autofill to only fill empty fields, not sure if it is still there as I moved on a year ago but it stopped a little of that annoyance.

After learning about how every app in your PC has unfettered un monitored access to the clipboard why in gods name would you do that? I explicitly make a point to never copy any password to the clipboard!

I'm still utterly perplexed about why every major operating system handles the clipboard this way. It's such an obvious privacy issue, and the fix seems really simple: only allow clipboard access when the user explicitly grants access through a system-provided user interface (whether that be a dialogue box, menu item or keyboard shortcut)

Apple's iOS 14 uses the half-solution of notifying the user after an application has read the clipboard. But at that point the end user is already a step behind the attacker, and mitigations may no longer be possible. Nevermind that this solution is dependant on the user noticing and understanding the implications of the clipboard access notification (the novice user is likely oblivious to the security risks)

Any password of sufficient strength would be slow and error-prone to copy manually. What’s the middle ground?

On a desktop, you can use KeePass and its variants to "auto-type". It'll switch focus to the last app you were in and type your username, a tab, your password, and then enter. No extensions or clipboard required. Just hit CTRL-SHIFT-V after highlighting the entry.

I tried using this but the final "enter" made me too uncomfortable. I really wish it was optional so I could verify where it just typed the password before submitting. After accidentally sending my password in the wrong field/window a couple of times I stopped using it entirely. Now I just copy-paste :(

You can edit how and what KeePass types, I always remove the final enter for comfort and safety reasons.

Ah wow, thanks for the tip. I guess you can edit the root group to change it globally? Thanks, I'll try this.

keepassxc has extra options in the auto-type menu for "username", "username<enter>", "password" and "password<enter>" in addition to the normal "username<tab>password<enter>"

That's paste

It looks like paste and it's almost the same from the user perspective, but the data never makes it to the clipboard, where it would be available to every running application.

From what I can see, KeePass does use the clipboard. [0]

[0] https://github.com/dlech/KeePass2.x/blob/VS2019/KeePassLib/N...

Sorry, I didn't mean to speak with any authority on the specifics of KeePass. I'm neither a developer nor a user. I was just explaining the parent.

That said, the implementation probably differs on different platforms. 1Password, for example, uses a virtual "keyboard" on Android.

That's a different option (CTRL-C). You can copy and paste the username and password. There's a default clearing timeout that's more to ensure the user doesn't accidentally paste it elsewhere. The auto-type option I mentioned is different.

> The auto-type option I mentioned is different.

It actually falls back to the clipboard [0], in a huge number of situations [1]. Basically, if Windows Forms isn't available/reliable.

[0] https://github.com/dlech/KeePass2.x/blob/VS2019/KeePassLib/U...

[1] https://github.com/dlech/KeePass2.x/blob/VS2019/KeePassLib/U...

> No extensions or clipboard required.

Paste draws from the clipboard.

You’re confusing console paste with windows paste

Yep, now I get it. Some addon does this override

Use a browser extension. For example, the 1Password extension uses (authenticated) IPC to talk to the app and then injects the password into the DOM directly.

Xkcd to the rescue? https://xkcd.com/936/

Gfycat already generates memorable URLs so it’s definitely possible. I myself do it manually nowadays (ie generate phrase password to be stored in manager so I can copy it manually if needed)

There is no way I could have convinced the people I have to use a password manager without the browser extension. So for those people it was either same password on all sites or a password manager with a browser extension.

I've never encountered any autofill instance where the effects of autofill wasn't immediately apparent (usually it's just the username and password). Having a special hidden fields in your form seems like a Bad Idea, but what is worrying is that there is nothing stopping more devs from implementing something like this. The only reason why we don't see it more often is probably because it takes more effort to make a "smart" form like this.

I use Firefox's own password manager (https://www.mozilla.org/en-US/firefox/lockwise/) inbuilt into the browser. I think it's a better compromise than having to expose sensitive credentials into my clipboard. IT works across devices too, so there's no copy pasting on my Android device which god forbid is probably reading my clipboard too (I know Facebook used to do that).

I do not see a reason to copy paste in any use case at all.

I just have autofill disabled. To fill in the password, I need to actually click some buttons.

this is why I use a password manager that has no network connectivity whatsoever, and no browser integration. keepassx with a v2.0 keepass format file.

it works from a local file on disk. yes, it's more inconvenient if I am away from the computer it lives on, and I need to update a password, I have to connect the VPN to my home office, ssh to it, and run 'kpcli' (a keepass format command line program), or run keepassx in a vnc-over-ssh session.

but that hassle is worth it in my opinion.