Clipboard API lacks a sensitive/private data type => password managers can't protect your passwords from leaking through Clipboard History or Cloud Clipboard
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, enhancement)
Tracking
()
People
(Reporter: aminomancer, Unassigned)
References
Details
There's this mozilla blog post about leaking passwords through windows clipboard history/syncing. about:logins is set up to avoid it per bug 1730194, but I can't see the bug so I don't know what else is planned. Most password managers are webextensions so they do not have access to nsIClipboardHelper and this behavior.
I am pretty sure there's no way to get the web Clipboard API to flip this private/sensitive value. So that should mean there's really no way for a password manager extension to safely handle your passwords while still using the actual system level clipboard. Whether you're copying a saved password or generating a new one, it poses a potential security risk, at least on some Windows platforms. At least, the current behavior with Bitwarden and 1Password is that passwords copied are immediately visible in Clipboard History on Windows 10 and synced if enabled.
Adding an optional second parameter aIsSensitive to the Clipboard API write methods would do the trick. If we want this to only be available to extensions, then another method could be added to the WebExtension clipboard API, like browser.clipboard.copyPrivate(...) to accept a string, an array of strings, or an object with properties imageData and imageType so you can also copy images securely.
I don't know whether to file this as a defect or an enhancement, since this seems to constitute a defect in that the password managers that most users use can not protect their data to the same degree that Mozilla considers necessary in its own password manager. It's nice to have another reason to use about:logins and hopefully Firefox's password manager can catch up, e.g. with system-wide autofill on desktop platforms. But either way, most people will probably continue using the password manager they already use, and won't even hear about this. But I think password manager developers will use this if it is exposed, or at least implement an opt-in setting for it.
|
||
Comment 1•3 years ago
|
||
The web platform already has a clipboard API in navigator.clipboard, which is also available to extensions. To avoid duplication and encourage standard APIs, the clipboard extension API is intentionally minimal; it only offers a way to copy images (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/clipboard/setImageData) because this was not possible at first.
The requested functionality here could also be useful as part of existing navigator.clipboard API.
And in fact, there is already a feature request for "Option to specify ClipboardItem is sensitive in .write() and .writeText()" at https://github.com/w3c/clipboard-apis/issues/154
There is not a Bugzilla ticket for the enhancement to navigator.clipboard yet, but once that exists, we could close this bug in favor of that one.
Side note: this problem is conceptually not Windows-only. E.g. the clipboard utility on KDE (a desktop environment for Linux) also maintains a (local) history. A "dumb" copy-and-clear implemented by copying an empty string could potentially be ineffective against actually removing traces of the password from the clipboard.
I also recall that there are Android apps that offer clipboard history functionality.
|
Reporter | |
Comment 2•3 years ago
|
||
Yes by Clipboard (capitalized) I mean the one exposed at navigator.clipboard. So this is essentially the same request as the gh issue you linked. re the clipboard API (lowercase) I just meant that if there are other concerns I haven't considered, it would be possible to limit the impact to just WebExtensions. But from my POV it seems much better for everyone to have access to this, especially considering that pw managers usually have websites where you can access your "vault" and they have copy buttons just like their browser extensions do. So an inconsistency there would be bad
|
|
||
Comment 3•3 years ago
|
||
We have decided to not offer an extension-specific API for this, but rather to encourage the adoption of it as part of the web platform - https://github.com/w3c/clipboard-apis/issues/154
Moving this bug over to the relevant component for further triage.
Description
•