| > isn't securing this one major IMO attack vector an improvement over not doing anything about it Unfortunately securing this attack vector is costly - in the sense of annoying the user with prompts and access grants. This is why even on mobile as you noticed, only browsers require user confirmation before allowing webpages access to the clipboard. You could maybe do something in between, like not allowing clipboard access to processes which don't have a foreground window visible to the user. But in practice, this attack vector is not exploited. If you are targeted, it's much more likely that a specific attack against the password manager is used, since it will extract ALL passwords, and not need to wait for one to show up in the clipboard: > KeeFarce allows for the extraction of KeePass 2.x password database information from memory. The cleartext information, including usernames, passwords, notes and url's are dumped into a CSV file in %AppData% https://github.com/denandz/KeeFarce |
You're making assumptions about what the implementation would be. There are many ways the UX could be unobtrusive. Besides, I'm not even proposing that the solution should be to restrict access to the clipboard. I'm just saying that there should be a secure channel between apps provided by the OS that can be used for these purposes. Designing and implementing that would be costly, sure, but I'm not an OS designer, and merely speaking what I would like to see as a user.
> But in practice, this attack vector is not exploited.
Of course it is[1]. It's not even an exploit, but an abuse of a glaringly insecure OS feature.
> If you are targeted, it's much more likely that a specific attack against the password manager is used
Again, why are you minimizing this clearly easy to abuse OS feature by comparing it to much more sophisticated exploits? Yes, there are other attack vectors. This thread is specifically about how the clipboard is trivially abused.
[1]: https://news.ycombinator.com/item?id=33330035