4 ms·

Wow. The password manager I've been using for the past few years has dedicated buttons/gestures for copying the password to the clipboard (like many others, I'd

Wow. The password manager I've been using for the past few years has dedicated buttons/gestures for copying the password to the clipboard (like many others, I'd assumed.) I feel like the expectations in this case are clear: a copied password should only accessible when the user "pastes" it. (The app even clears the clipboard after a certain amount of time, making it seem like the only weak point in the system is the paste functionality.) To find out that this is not the case is pretty mind blowing. Does anybody know of any good reasons why the clipboard shouldn't be secure?

kalleboo 7y ago
> Does anybody know of any good reasons why the clipboard shouldn't be secure? Seems like a UI issue to me. Right now apps themselves invoke the paste command (e.g. they can put a "paste" button in their UI). If you remove clipboard access from programs, the UI would have to be presented by the OS. Requiring paste to be initiated by the OS may work alright for text boxes (but you'd now have to sandbox all the text boxes to avoid the app simulating taps), but it wouldn't work for say, pasting images. Another option is to add a dialog box every time asking the user "did you REALLY want to paste?", but that will quickly get annoying.
- etherealG 7y ago
  I can imagine something along the lines of checking whether user interaction was the root cause of getting access to the clipboard as a middle ground... e.g. on web, popup blockers work this way. If a user interacts with a button, and that javascript series of functions opens a popup, it is allowed. If a non user interaction function in javascript, say a running ad, tries to open a popup, it is blocked. Could try the same approach, where only if the user initiated the current running series of functions, would it be allowed to access the clipboard. Or even ask for elevated user interaction functions, so that security teams would have an explicit list of elevated functions that are allowed to access sensitive data, allowing for easier manual checks. Anything else would have the annoying confirmation.

kalleboo 7y ago

> Does anybody know of any good reasons why the clipboard shouldn't be secure? Seems like a UI issue to me. Right now apps themselves invoke the paste command (e.g. they can put a "paste" button in their UI). If you remove clipboard access from programs, the UI would have to be presented by the OS. Requiring paste to be initiated by the OS may work alright for text boxes (but you'd now have to sandbox all the text boxes to avoid the app simulating taps), but it wouldn't work for say, pasting images. Another option is to add a dialog box every time asking the user "did you REALLY want to paste?", but that will quickly get annoying.

etherealG 7y ago
I can imagine something along the lines of checking whether user interaction was the root cause of getting access to the clipboard as a middle ground... e.g. on web, popup blockers work this way. If a user interacts with a button, and that javascript series of functions opens a popup, it is allowed. If a non user interaction function in javascript, say a running ad, tries to open a popup, it is blocked. Could try the same approach, where only if the user initiated the current running series of functions, would it be allowed to access the clipboard. Or even ask for elevated user interaction functions, so that security teams would have an explicit list of elevated functions that are allowed to access sensitive data, allowing for easier manual checks. Anything else would have the annoying confirmation.