Android clipboard is vulnerable to hijacking
emilecantin opened this issue · 20 comments
As evidenced here, it is apparently possible for any app on the device to listen for changes on the system clipboard and to get its contents.
Another password manager, Keepass2Android, implements a keyboard to get around this problem. I think we should do the same.
Thanks for the info. However, I do not see the link between a keyboard and the clipboard. Do you mean they implemented an android keyboard app that recovers the passwords from the app?
The app implements an Android keyboard, which is available as an input method (it is not a separate app, it is bundled with the app). Usually, this is a regular keyboard (a bit shitty, however), but when there is an entry being displayed inside the app, the keyboard transforms and only has 2 buttons: username and password.
This should be feasible. I've read some papers that confirm the problem you mentioned earlier. In v1.2.0.9 the copy on decrypt will be disabled by default.
Would that mean users have to permanently use this keyboard? What if they like 3rd party keyboards?
On the other hand, if users have to manually switch their keyboards back and forth just to copy a password, I'd consider this a problem.
In keepass2android, you can either use their keyboard full-time (I didn't), or I could switch keyboards when filling login forms. I agree that this is a bit of a usability problem, but Android 5.0 makes it relatively easy.
Also, it seems that LastPass implements uses the new accessibility APIs on Android 5.0 to auto-fill forms in other apps. That may be another avenue.
There is also the question of why this is an issue at all. On the desktop for example, I imagine this to be equally possible to monitor the Clipboard (in fact, I rely on it for the GNOME Clipper extension). Keepass, Pass and co however, are storing into the clipboard nonetheless.
I agree, it is also an issue on the desktop. To avoid this, Keepass implements an auto-type functionality, and LastPass & co use a browser extension to auto-fill login forms.
It is true that it is often more convenient to use the clipboard, but it may be pertinent to have an alternative solution.
Keepass, Pass and co however, are storing into the clipboard nonetheless.
Agree. This is not such a big issue for me.
Keepass and Pass are restoring the clipboard after some seconds. Would this make it more secure? I fail to see how, but maybe?
We already clear the clipboard after a few seconds.
The keyboard solution, it does seem like a bad idea for the users. Maybe going through accessibility service (https://developer.android.com/guide/topics/ui/accessibility/services.html) might be good idea for a future feature.
Accessibility actions do indeed seem to provide a facility to auto-fill some values. But I don't think it would be worth the effort. Consider these problems for example:
- How is this auto-fill initialized?
- How does pwd pick the right password/user, especially in a browser?
- How does pwd find the right data in the unstructured form that pass allows?
- What is the fallback if all this complicated stuff fails?
Maybe it is more worthwhile to investigate how to make using the Clipboard safer? For example, how about to overflow the Clipboard with random information in order to decrease the likelihood that a sniffer can match username and password?
I agree that we need more investigation. Putting garbage in the clipboard and ending with the password is a good idea indeed.
- For the two first questions, we can use the intent system. When the user wants to fill a password the application pwdstore launches, the user selects which password to decrypt and on result fills the data in the focused field in the current view.
- Pwdstore uses exactly the same behaviour as pass, ie. we only get the data set as password and not the extra information.
- The fallback is the classical copy/paste. This will not be removed.
@zeapo Using the intent system seems to make this feasible imo. Somehow when I thought "auto-fill" I assumed fully automated ;). I am still unclear though how pwdstore would get the username. The password is ,as stated in Pass docs, always first line of decrypted file. The file name could be anything. Domain name, username, some arbitrary reminder label...
We will (for the moment) keep exactly the same behavior as pass. The username is up for the user to write it down.
However, in a near future, we are looking into improving the way the extra-information is displayed by adding some meta-data describing the content. For instance:
<mypasswordhere>
# Form
username: <myusername>
url: <websiteurl>
# End Form
(just an idea)
We could then have a semi-automated service. It will also improve the output of the extra-information when we decrypt the password.
Sounds good, I suggest opening a new issue for metadata.
What about this issue now? Postponed? Closed?
Hi,
Its a nice implementation, but if (like me) you use Password Store in a Chrome context, its seems not working (because its a Website not an app). The idea of an input method is still not an option ?
[Edit] I have just seen the todo, nevermind great if its still something to implement.
It is still a possibile option I think. I believe in the latest versions of Android switching keyboards is more convenient and usable too. I'll work on it but no eta
In kp2a(keepass2android), you can have it automatically switch to the kp2a kb and back (doesn't seem to work inside terminals, but eh).
Also, pass uses "username" as the standard field. passff uses "login", but that's configurable iirc
When using autofill, does it utillize the clipboard? It requested some sort of permisson for autofill so I assumed this was some sort of android 5.0 feature that circumvents the need for the (insecure) clipboard
Autofill does not use the clipboard and the recently added share button allows to share the password in clear text to another app if needed.