Windows 10 (and later): clipboard history keeps passwords after being copied from BW desktop app or browser addon

[MPeti1]

Describe the Bug

When I copy a username or a password, or anything else from Bitwarden Desktop, the copied data will be stored in Windows 10's clipboard history, which may be set up in a way to upload the clipboard history to synchronize with other devices

Steps To Reproduce

0. Turn on clipboard history
   I. Open the Settings app (Windows + i)
   II. Open the System category
   III. Select clipboard from the list on the left
   IV. Turn on clipboard history
1. Copy a password or an other field from Bitwarden Desktop (or just use the password generator)
2. Paste it into the program where you needed that password for logging in (or not)
3. Check the clipbaord history with the Windows + V key combination

Expected Result

The password (or any other field copied from Bitwarden, though that could be a setting) shouldn't be saved to the clipboard history

Actual Result

If you wait until your clipboard is automatically deleted (assuming the appropriate setting is used), pressing Ctrl + V does not result in inserting the password, because it's been removed from the clipboard. But if you press Windows + V, the password is still there at the top of the list

Environment

• Operating system: Windows 10
• Build Version (go to "Settings" → "About"): 1.22.1

[AngelusGi]

same on:

• Windows 10 Enterprise (build 19042.508, Version 20H2)
• Bitwarden version 1.22.2

[jdvmanen]

Quite a nasty bug... you expected a empty cliipboard but it is plain saved to the clipboard history. With this feature, the desktop app becomes a security breach...

[MPeti1]

Yes. Even better, it seems no one is interested in it.

[MPeti1]

Also, if I remember correctly clipboard sync is already turned on when you enable the history, so if someone using the history hasn't disabled that, let alone the possibility that Microsoft will never delete what is uploaded, and that MS employees could have access to clipboard history, but if someone gains access to your MS account, and log in with it on an other PC, then your copied passwords will be synced instantly, and it won't matter if you delete the entry in the history or not

[kspearrin]

Is there a way to programatically manipulate the windows clipboard history?

[AngelusGi]

Using WinRT you can manage all the clipboard.
WinRTClipboard
I've read about this module wrapper from WinRT to NodeJS but never used it NodeRT

[cscharf]

We currently use nodeRT for Windows Hello capabilities, so we could look into utilizing this for manipulation of the clipboard history @kspearrin .

[sylveon]

There is no need to manipulate the clipboard history. There is a flag to hide content from the history (and clipboard sync).

See this page for the classic clipboard API: https://docs.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats#cloud-clipboard-and-clipboard-history-formats
This one for the WinRT clipboard API: https://docs.microsoft.com/en-ca/uwp/api/windows.applicationmodel.datatransfer.clipboardcontentoptions

[Sysadminatschool]

Can we expect to see this resolved in an upcoming release? Trying to work around it is rife with issues, and it's an obvious sizable risk.

[cscharf]

This has not yet been assigned for development and is likely something we'll address towards the end of this quarter.

[Sysadminatschool]

This has not yet been assigned for development and is likely something we'll address towards the end of this quarter.

Thanks. I appreciate the reply. Looking forward to seeing it, as Bitwarden has become an important tool for us.

[moggymew]

Bitwarden Desktop version: 1.24.6
Windows version: 1909 / OS Build: 18363.1379

I just discovered this independently today. The only way I have found to prevent this is to ensure that Windows > Settings > Clipboard history is turned OFF.

Given that this could potentially be very dangerous, and if it is not possible to override such Windows behaviour via Bitwarden, then perhaps it should be noted clearly in the help that Windows Clipboard history needs to be turned off?

[Mrxx99]

Here is how it was fixed in KeePassXC: keepassxreboot/keepassxc#5853
It seems only a additional metadata in the mime data has to be set.

Is there also an issue for the browser extensions? The have the same issue.

[eliykat]

Related to #2633

[Trouffman]

I created a duplicate for this earlier bitwarden/desktop#1017

Here are some info I found looking for this problem:
Electron support custom mime type : electron/electron#9243

On Windows 10 this is the mime type required :

Use custom mime type ExcludeClipboardContentFromMonitorProcessing and set type to CF_TEXT (or in. 1)

[eliykat]

Thanks @Trouffman; it's been a few months since I last looked at this, I'll take another look and see if any of the options you've raised might give us a workable solution.

[Mrxx99]

Any news on this? Also please don't forget the browser extension has the same issue.

[ThisIsDanny]

Am curious about any news on this as well since I just switched over from KeePass which didn't have this.

[zbynekdrlik]

Same here, migrated from KeePass where it was working - now all my copied password accessible n clipboard history which I use frequently. So please look at it ;)

[moggymew]

Bitwarden Desktop version: 1.29.1
Windows version: 1909 / OS Build: 18363.1379
Already commented on this back in March 2021 with version 1.24.6.
This is still an issue today quite a few revisions later. Bitwarden - is this going to get fixed soon?

[Snowworm3000]

It's unfortunate that this issue doesn't have a higher priority.
For now, got to windows settings > system > clipboard > clipboard history, and toggle the clipboard history off. Although, this obviously means you won't be able to use the clipboard history feature. It's better to do this than compromise the security of your passwords, especially as you are using this password manager for that very reason.
I'll look into helping resolve this issue once I've got a better grasp of electron and angular (I use react 🙁).

[marcinsmialek]

@Snowworm3000 This is one of the reasons why I switched to other password manager

Perhaps you'll find the following links useful. It's not JS/TS, but they describe / demonstrate the new clipboard features:

• https://docs.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats#cloud-clipboard-and-clipboard-history-formats
• https://docs.microsoft.com/en-us/samples/microsoft/windows-universal-samples/clipboard/
• https://stackoverflow.com/questions/53190273/bypass-clipboard-history-in-the-windows-10-october-2018-update/57530935#57530935

There may be ready to use wrappers for this to use in Electron. If you come across other security-related libraries, adding Secure String support would be useful too - so other programs can't read clear-text passwords from Birwarden Desktop memory so easily.

[zbynekdrlik]

Clipboard history is everyday productivity feature. I don't think that switch off something what we are using so frequently should be low priority.

[Snowworm3000]

@Snowworm3000 This is one of the reasons why I switched to other password manager

Perhaps you'll find the following links useful. It's not JS/TS, but they describe / demonstrate the new clipboard features:

• https://docs.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats#cloud-clipboard-and-clipboard-history-formats
• https://docs.microsoft.com/en-us/samples/microsoft/windows-universal-samples/clipboard/
• https://stackoverflow.com/questions/53190273/bypass-clipboard-history-in-the-windows-10-october-2018-update/57530935#57530935

There may be ready to use wrappers for this to use in Electron. If you come across other security-related libraries, adding Secure String support would be useful too - so other programs can't read clear-text passwords from Birwarden Desktop memory so easily.

Thanks, I'll have a look at them. Currently I'm having an issue with the initial npm install command. It seems like there is an issue with npm detecting the newer version of visual studio (2022). I've looked at various stackoverflow threads, but I still can't get to the first run of this project which is annoying. I have experience with npm, but I am quite new to visual studio and electron. I can get back to you with the actual logs when I'm at my computer if you'd like to help me. Sorry if you think this is better asked somewhere else.

[MCOfficer]

Thanks, I'll have a look at them. Currently I'm having an issue with the initial npm install command. It seems like there is an issue with npm detecting the newer version of visual studio (2022). I've looked at various stackoverflow threads, but I still can't get to the first run of this project which is annoying. I have experience with npm, but I am quite new to visual studio and electron. I can get back to you with the actual logs when I'm at my computer if you'd like to help me. Sorry if you think this is better asked somewhere else.

This seems very familiar, i'm pretty sure I had the same issue with NodeRT. Does this ring a bell? I eventually got it to work with VS2019 (which also isn't supported), so there's a chance I can help you. There's 15 people subscribed to this issue though, plus lord knows how many are watching the repo, so perhaps it would be better if you opened an E-Mail thread or something with everyone who's interested in debugging. A separate issue might also suffice, after all this is an error with compiling buildwarden.

[Snowworm3000]

Thanks, I'll have a look at them. Currently I'm having an issue with the initial npm install command. It seems like there is an issue with npm detecting the newer version of visual studio (2022). I've looked at various stackoverflow threads, but I still can't get to the first run of this project which is annoying. I have experience with npm, but I am quite new to visual studio and electron. I can get back to you with the actual logs when I'm at my computer if you'd like to help me. Sorry if you think this is better asked somewhere else.

This seems very familiar, i'm pretty sure I had the same issue with NodeRT. Does this ring a bell? I eventually got it to work with VS2019 (which also isn't supported), so there's a chance I can help you. There's 15 people subscribed to this issue though, plus lord knows how many are watching the repo, so perhaps it would be better if you opened an E-Mail thread or something with everyone who's interested in debugging. A separate issue might also suffice, after all this is an error with compiling buildwarden.

Thanks, the link to the github issue seemed to resolve my problem, specifically downloading the windows 10 sdk. I still have an issue with node-gyp, but the issue seems to be universal across my system because it fails in directories other than the Bitwarden clone directory, so if I can't resolve it myself I'll ask elsewhere (probably on the node-gyp github repo).

[Snowworm3000]

I've started writing the code to resolve this issue; however I'm unsure as to how I should approach the problem.

I'll detail the approach I've taken to fix this issue.
To prevent syncing copied text to clipboard history, the copied text must contain this ExcludeClipboardContentFromMonitorProcessing mime type, which is detailed here.

To do this, I researched and tested the electron clipboard api. It looks like the only way to use custom mime formats is to use clipboard.writeBuffer which was suggested by @Trouffman however, I can't find a way to do this because using the example in the documentation copies some unknown format which no windows program can paste other than the electron clipboard (which can read and decode the buffer). Perhaps I am doing this incorrectly.
Another issue with electron clipboard is that I can't copy multiple custom clipboard formats (which I think is required to use the mime type as well as the normal text). I have noticed the clipboard.write method, but this doesn't support custom mime types.

Does anyone know if this is possible with the current electron clipboard implementation, is there a way to do this with clipboard.writeBuffer that I haven't been doing?

If this isn't possible with electron clipboard, maybe I could contribute to electron as well 😆.
As another alternative, I could use native windows code maybe using node-ffi or use the windows api with c++/c# but this would make it more difficult to port to linux as well.

[sylveon]

Port to Linux? This is Windows specific functionality, there is no point in porting to Linux.

[Hinton]

@Mrxx99 @thericle We will focus on the desktop application since to my knowledge there is currently no native APIs providing this capability in the browser extension.

[sylveon]

@Hinton would it be possible to have the browser extension do copies through the desktop application when they are paired together? Doesn't seem too far fetched since it can do biometric unlock.

[Hinton]

@sylveon it's technically possible but we will initially focus on resolving the desktop portion and may expand the scope later.

[makacenko]

Three years without progress on this SECURITY issue? I can't believe...

[heathlarsen]

Three years without progress on this SECURITY issue? I can't believe...

The few replies above you are from the Bitwarden team who are now beginning to work this. Yes it's taken them far too long, but let's give credit where it's due. ❤️

[thericle]

@Hinton

We will focus on the desktop application since to my knowledge there is currently no native APIs providing this capability in the browser extension.

While I appreciate the intention and the effort, if my estimation is correct that the vast majority of Bitwarden's use on computers comes from the browser extension, solving this just for the desktop application wouldn't be far in practice from not solving it at all. Sorry if I'm being ungrateful here, that's not my intention.

[oguzhane]

We will focus on the desktop application since to my knowledge there is currently no native APIs providing this capability in the browser extension.

Speaking of clipboard within the context of browser extension, i was thinking how often a user really need to copy credentials from the extension to OS's global clipboard.

OS's global clipboard is the attack surface here. In order to minimize that risk,

would it be a better feasible option that the extension should maintain an internal clipboard independently from the OS?

So, it can be pasted in any tab/website but not outside the browser.

[Mrxx99]

@oguzhane
Speaking of clipboard within the context of browser extension, i was thinking how often a user really need to copy credentials from the extension to OS's global clipboard.

I do this quite often, when I want to copy a password to another location I don't always open the desktop app, as the browser is often already running with the extension unlocked.

[rollsch]

I've been using bitwarden lately. When it can't auto fill for whatever reason I use the clipboard and it auto clears the clipboard after 10,30,60,never seconds via integration with the desktop app.

What is stopping it scanning the entire clipboard history and not just the latest entry?

What about a simple c# program that runs periodically scanning the clipboard history? All it would need is a list of secured hashes available to it via a temporary file that is exported whenever bitwarden users the clipboard? Might be a bit hacky but it work and be secure.

This would work for the browser plugin as well as it can write to disk afaik.

%temp%/bitwarden/clipboardhashes.csv
Hash, dateutcopiedtoclipboard

If the hashes are cryptographically secure and deleted as soon as the c# service runs this would avoid needing to use any windows apis and it would work across all browsers and future desktop applications.

Can anyone see anything insecure about this? This c# project could accept hashes from other software or even maintain a hard coded list should you accidentally put it in your clipboard history another way.

[rollsch]

Here is an example of how you could get the Chrome plugin to write the hashes to the c# program. If someone coukd look after my kids for a day I'd write this program.

//make this a service that runs in the background 
class Program
{
    static void Main()
    {
        // Read the JSON message length from standard input
        var buffer = new byte[4];
        Stream stdin = Console.OpenStandardInput();
        stdin.Read(buffer, 0, 4);
        int length = BitConverter.ToInt32(buffer, 0);

        // Read the JSON message content
        buffer = new byte[length];
        stdin.Read(buffer, 0, length);
        var json = Encoding.UTF8.GetString(buffer);

        // Deserialize the JSON message to a dynamic object
        var message = JsonSerializer.Deserialize<dynamic>(json);

        // Extract the text from the message 
        var text = Convert.ToString(message.text);
        //parse the hashes then scan the clipboard history for any matches removing them

//TODO store a list of hashes recieved with a date stamp

using Clipboard = Windows.ApplicationModel.DataTransfer.Clipboard;

Task.Run(async () => {
    var items = await Clipboard.GetHistoryItemsAsync();
    foreach (var item in items.Items)
    {
        string data = await item.Content.GetTextAsync();
        Var Words = Data.split(' ') ;
        Foteach(var word in words) {
            Var hash = hash(word) 
            If hashes.Contains(hash);
           ,//TODO - remove clipboard entry
        } 
    }
});

    }
}

2. Chrome Extension to Send Text to the Native App
   You need a manifest.json file to define the extension and its permissions, a background.js to handle messaging, and a native-messaging-hosts/com.my_company.my_application.json file to set up native messaging.

Here’s what the background.js might look like:

javascript
Copy code

chrome.runtime.onConnectExternal.addListener((port) => {
  port.onMessage.addListener((message) => {
    console.log("Received message:", message);
    const text = message.text;
    if (text) {
      // Send the text to the native application
      port.postMessage({ text });
    }
  });
});

3. Native Messaging Host Manifest
   This JSON file registers the native application with Chrome. Replace PATH_TO_YOUR_APP with the actual path to the executable of your native application.

json
Copy code
{
  "name": "com.my_company.my_application",
  "description": "My Application",
  "path": "PATH_TO_YOUR_APP",
  "type": "stdio",
  "allowed_origins": [
    "chrome-extension://your-extension-id/"
  ]
}
4. Chrome Extension Manifest File (manifest.json)
Add "externally_connectable" and "permissions" fields to allow the extension to connect to the native application.

json

Copy code
{
"name": "My Extension",
"version": "1.0",
"manifest_version": 3,
"action": {
"default_popup": "popup.html",
"default_icon": {
"16": "images/icon16.png",
"48": "images/icon48.png",
"128": "images/icon128.png"
}
},
"permissions": ["nativeMessaging"],
"externally_connectable": {
"ids": [""],
"matches": ["://.example.com/"]
}
}

Ensure you have the required runtime (.NET Core or .NET 5/6+) installed on the system where you're running the C# application, and replace placeholders like "your-extension-id" and "PATH_TO_YOUR_APP" with actual values. Always handle the user's data securely and respect their privacy.

Here is how you can access the clipboard from net 5.0

https://stackoverflow.com/questions/65385486/how-do-i-get-a-list-of-all-data-from-clipboard-history-in-c

using Clipboard = Windows.ApplicationModel.DataTransfer.Clipboard;

Task.Run(async () => {
var items = await Clipboard.GetHistoryItemsAsync();
foreach (var item in items.Items)
{
string data = await item.Content.GetTextAsync();
MessageBox.Show(data);
}
});

[sylveon]

We should not write out the raw password to the drive for any reason.

[rollsch]

Of course that would be insanity. Writing a cryptographically secure hash however and sending it via a Windows pipe sounds pretty secure to me.

[oguzhane]

I do this quite often, when I want to copy a password to another location I don't always open the desktop app, as the browser is often already running with the extension unlocked.

I see your point and how convenient user experience is there. My concern here, that probably goes out of the scope of this thread, was whatever goes into OS's clipboard is never safe because Windows's clipboard is not at all. Any win32 process can monitor every change in clipboard and read the content. So, i thought scoping down accessibility of sensitive information could be a good trade-off security wise.

I couldn't find any native/standart way that addresses this security concern in windows. Not sure about ExcludeClipboardContentFromMonitorProcessing though..
This tool https://www.nirsoft.net/utils/inside_clipboard.html can be used for testing. I tested it with KeePassXC, it can capture passwords once copied to clipboard.

see: https://www.ctrl.blog/entry/clipboard-security.html

I could also think of emulating keystrokes could be another way to avoid clipboard.

[sylveon]

This is not a concern because if something you don't trust is running locally, they could defeat whatever method is used to hide the credentials, or could directly read the memory of bitwarden/the target process. Writing to drive is a concern because unless encrypted, this data could be read off the drive, even if the file is deleted.

Just using the existing IPC channel that is used for biometric unlock to also copy credentials will work just fine. But that's out of scope for the initial implementation.

[oguzhane]

This is not a concern because if something you don't trust is running locally,

By saying this, we seem to be placing the end-user in position that she should be responsible to have awareness for all the running programs with all the abilities they perform.
This is an unrealistic assumption to make especially for less technical users whereas that should ideally be addressed at the OS level. I'd find it beneficial for the user's security and privacy. It is the same underlying reason why Android/iOS have decided to bake some clipboard protections not long ago.

they could defeat whatever method is used to hide the credentials, or could directly read the memory of bitwarden/the target process.

Right, a process with such root privileges infected the OS could directly read memory but i don't think that applies to what i meant we are interested in to overcome within the context of ^.

[sylveon]

There is no need for admin privileges to achieve this on Windows. An unelevated process can freely call ReadProcessMemory on every unelevated process running as the same user. There is little isolation between processes. It's pretty much pointless to try to defend Bitwarden against such attacks, it requires OS-level isolation which doesn't exist.

[oguzhane]

Thanks for highlighting ReadProcessMemory. It indeed would be pretty much useless.

[Hinton]

Quick update, the desktop portion of this work is implemented with #4516. And should roll out in the next release.

I will remove the desktop label from this issue to capture the remaining issue.

[sylveon]

Does this also cover the scenario of ctrl-c and right-click > copy, rather than clicking the copy button in the field? I don't see usage of the copy event explicitly called out in the PR.

[Hinton]

@sylveon not currently. I've started an internal discussion for this though as one way to implement it would include "clear clipboard" which is a functional change.

[Shadoweee77]

Any news for browser addons?

[peterfox1]

This is a good default, but it could also be nice if was an option to disable this and allow passwords in the clipboard history again. If you have a secure environment or/and low impact logins and don't have clipboard syncing, it was very convenient to be able to copy multiple details of a login at once. Particularly for the desktop app since you'd always be using that in cases where auto-fill (browser add-on) was unavailable.

[zwsren435]

I completely agree that there needs to be a setting for this. I understand that different users will have different preferences and risk-tolerances, but forcing this feature down everyone's throats, especially when there is no system-wide autofill for Windows, is not cool.

Just like with so many other of these divisive features, making everyone happy is as simple as adding an on-off switch.

[miditkl]

It needs to be fixed asap. Every password I used was exposed without me knowing.