-
-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Android clipboard is vulnerable to hijacking #50
Comments
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. |
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. |
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:
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.
|
@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:
(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, |
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. |
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.
The text was updated successfully, but these errors were encountered: