Copy-paste password is a serious security flaw

[Vlcoun]

Any program, white or black, can access the clipboard. It's a good system - as long as the user does not copy-paste the passwords!

[adamczykm]

@Vlcoun Got any other ideas? If people had to write these passwords by themselves they wouldnt use mpw at all. The problem with clipboard is that it is broken by design :|

[djrieger]

What about letting users copy the passwords if they want to and also offering the alternative of having MPW "type" the selected password directly into the input field that had focus before MPW was invoked in the previously focused application? (Thinking about the Mac OS X GUI version here)

[GrzegorzDrozd]

Is it possible somehow to do drag and drop ? Are there any API's ?

[lhunath]

Drag-and-drop operations cause the data to be copied to the NSDragPboard pasteboard. All inter-process communication like this tends to happen through the pasteboard server. I'm not 100% clear on the extent to which usage of the general pasteboard can be secured. It's possible to request a private pasteboard, but then the receiving application has to know the private pasteboard from which to read the data. This is not an option when transferring information to a generic client.

I'm not sure whether NSDragPboard items on the general pasteboard are accessible by clients other than the host and receiving client. But most likely, they are.

I'm not sure if it's possible to use NSPasteboardWritingPromised to avoid writing the actual password to the pasteboard until the recipient needs it and use that to validate whether the recipient should indeed receive the password.

Another possible avenue is to use AXUIElement to write the password directly into the other client program's text field. This would require the user to give Master Password the necessary privileges under Privacy -> Accessibility.

[GrzegorzDrozd]

And on non-mac's ?

[lhunath]

There isn't a generic answer for this. Every platform will need to be evaluated individually.

Master Password's default passwords are word-like, so it is possible to store them in short-term memory long enough to transfer them, for most people. Nobody is forcing users to copy the passwords, it is merely a feature.

[djrieger]

Regarding AXUIElement on Mac OS X this would mean something along the lines of http://stackoverflow.com/a/22042458 right?

[lhunath]

Probably!

[Vlcoun]

Is there any possibility for MPW to "clear clipboard after itself"?

2016-11-10 15:53 GMT+01:00 Michał Adamczyk notifications@github.com:

@Vlcoun https://github.com/Vlcoun Got any other ideas? If people had to write these passwords by themselves they wouldnt use mpw at all.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Lyndir/MasterPassword/issues/140#issuecomment-259709945, or mute the thread https://github.com/notifications/unsubscribe-auth/AEW_8v_aS6cTpaz-mi6ynno9s8xjNI4Eks5q8y_jgaJpZM4KuvCR .

[lhunath]

Is there any possibility for MPW to "clear clipboard after itself"?

This doesn't help anything, it's nothing but an illusion of security. Everything that goes on the clipboard is public to all apps on the computer, no matter how brief it exists on the clipboard. This is why clipboard apps are able to record a history of all things that appear on the clipboard.

There is a point at which you need to agree that whatever you run on your computer depends on you trusting it. All apps that are running in user space on your PC are capable of nearly anything they like. Removing passwords from the clipboard isn't exactly a huge win in security. If you do not trust the apps you run on your PC, the clipboard isn't the only pathway for them to invade upon your security, and Master Password can't help you with the many others. This issue feels like closing the window but leaving the door open.

[fallerOfFalls]

Looking into how other password apps deal with this, could an Accessibility Service be used for Android?

[lhunath]

I'll definitely look into it, thanks @fallerOfFalls!

[mylainos]

Removing passwords from the clipboard isn't exactly a huge win in security. If you do not trust the apps you run on your PC, the clipboard isn't the only pathway for them to invade upon your security, and Master Password can't help you with the many others.

I agree, the access to the clipboard by any app isn't a problem. But if you copy your password and close MPW, you can still paste it. So if someone have access to your session, he can know your password if you haven't copied something else.

KeePass clear the clipboard after 10 sec, maybe we can do something similar.

[Binero]

If the security of your computer is compromised, surely there is not much this application can do. Even if somehow you prevent the malicious application from reading the clip board, it can probably just act as a keylogger instead?

[adamczykm]

I've just read that some password managers input passwords by emulating keystrokes.

sob., 11 lut 2017 o 13:42 użytkownik Jeroen Bollen notifications@github.com napisał:

If the security of your computer is compromised, surely there is not much this application can do. Even if somehow you prevent the malicious application from reading the clip board, it can probably just act as a keylogger instead?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/Lyndir/MasterPassword/issues/140#issuecomment-279141545, or mute the thread https://github.com/notifications/unsubscribe-auth/AEx_cu4kn57jYfxu1-cB-2YAN0jjsSfOks5rbazFgaJpZM4KuvCR .

[wangkesen]

There's a possibility of Keyloggers as well, if anything I feel safer using the copy and paste function within iOS , also due to the fact the passwords can remain hidden when you go to grab them from the app, also ruling out screen loggers as well if someone were to be susceptible to that. Is it possible for clipboard to automatically purge the last pasted item?

[toonn]

I agree clearing the clipboard doesn't improve security in case a device is compromised. Another scenario might be handing your phone to someone to show them some pictures or something, clearing the clipboard would prevent them from logging in to whatever you last copied the password for.

[Mattiaslndstrm]

Here is a tactic used by KeePass: https://keepass.info/help/v2/autotype_obfuscation.html

[charliemb2]

In a first attempt to solve this, KeepassXC first tried a connection to a browser extension via https. They eventually discovered that the initial handshaking to the https daemon could be eavesdropped and therefore compromised. So since about January they introduced a new browser extension, KeePassXC-Browser, and depreciated the use of https.

They've solved this now by having KeePassXC, the db, talk to the browser extension, KeePassXC-Browser, directly via STDIO.

https://github.com/keepassxreboot/keepassxc-browser

How it works There are two methods which you can use KeePassXC-Browser to connect to KeePassXC: 1...

2. KeePassXC-Browser communicates directly with KeePassXC via stdin/stdout. Using native messaging directly is a more secure as it ensures the traffic between KeePassXC and KeePassXC-Browser is direct. This method launches KeePassXC every time you start the browser and closes when you exit. This can cause ...

This might solve it for all but iOS. iOS still does not allow browser extensions on Safari or Chrome. However, Firefox does support extensions, so that can be an option for those that want this solved in iOS.

[lhunath]

This is far too convoluted. Every introduction of complexity is a threat to the security model. Think of it like a chain, every time you make the chain longer, you make it more likely to break than it was before (just like their HTTPS idea was); only one link needs to be weak for the whole to be worthless.

Furthermore, Master Password has no need for any of this since a Master Password extension can just compute the secrets itself. There is no need for establishing a secure channel with an authority (as you say KeePassXC-Browser does with KeePassXC).

That said, I have not authored any browser extensions. I also find this problem low-priority. We are trying to protect the user against a compromised system by using that compromised system's sysops. That's like fighting an army in the bailey - it's a losing battle. You have to yield what is lost and fall back to the walls. The only decent way of approaching this type of problem is by moving Master Password off the system. One way of doing this is by implementing it in a hardware token (eg. a secure USB hardware implementation of Master Password).

[toonn]

Someone pressing C-v in notepad is a very different form of "compromised system" than a MITM though. Expiring the clipboard'll at least cover the cases average users might worry about.

[lhunath]

I'm mostly referring to the last post in that; the clipboard use should ideally be made exclusive to interactive use and shielded from programmatic access ; though this is a platform-specific problem.

For macOS, there is EnableSecureEventInput and there is the method Keychain uses to copy data into the pasteboard that applications can't see. I don't actually know how they do that – it would be great if we could access that API.

Interesting reading: https://developer.apple.com/library/content/technotes/tn2150/_index.html

[charliemb2]

The only decent way of approaching this type of problem is by moving Master Password off the system. One way of doing this is by implementing it in a hardware token (eg. a secure USB hardware implementation of Master Password).

...And perhaps have the hardware token talk directly to an InputStick for generating actual keystrokes on the target system. Or... how else can the generated passwords be communicated? Are you thinking a Raspberry Pi with some sort of display? The processor on a Raspberry Pi is quite slow, perhaps too slow for a good user experience. Actually, InputStick will work for for most devices but not iOS or Android.

This is an interesting approach.

[Edit: The InputStick works for iOS and Android as an output. What I meant above by "will work ... but not iOS or Android" was that because of the InputStick's large standard USB connector for a USB-A connection to a notebook or desktop computer, it won't plug into an iOS or Android device, physically speaking. As to whether it would work as an input otherwise, I don't know.]

[lhunath]

The hardware device can emulate a keyboard akin to Yubico. I haven't looked into InputStick yet; but ideally it would be something maximally portable and minimally dependent on externals.

[lhunath]

Project has moved to https://gitlab.com/MasterPassword due to GitHub ownership change. This issue has been migrated, feel free to follow the conversation there.