PC keyboard autofill

[ashkitten]

Would it be possible to have the device act as a Bluetooth/USB keyboard and type the password into a connected computer automatically? That would be a fantastic and very useful feature :)

[wongma7]

see here for discussion https://github.com/zeapo/Android-Password-Store/issues/145 i don't think it is possible but maybe something has changed since

[zeapo]

still not possible. the thing is that we have three solutions:

• preferred: write our own pc/mac/linux software that will act as a keyboard and communicate with it (we'll have to handle security and so on)
• less preferred: use something like input stick
• not conceivable: use low level api (need root) to make the device act as a keyboard

[ashkitten]

What if we hosted a web service (possibly a chrome extension or something) that you can use to automatically copy the password to your browser's clipboard? Just an idea, it would need some additional security obviously.

[zeapo]

That's one way to implement the preferred solution I was talking about. However, running it on Chrome is not a good solution as not all of us uses Chrome.

[ashkitten]

Most modern browsers support extensions with the same basic format. It would most likely be trivial to get it working on Firefox, Safari, Opera, and Edge as well. We can also have a website as an alternative if your browser does not support extensions.

[jumper047]

There is an extension for keepass2android, named k2a usb keyboard. It uses custom kernel, so this is not a silver bullet. But it works fine if device supported it.

[danielvandenberg95]

Out of curiosity, what advantages would this have over simply using pass installed on the target PC?

(I mean, I could think of one, http://www.knocktounlock.com/, but I'm curious to yours.)

[ashkitten]

Sometimes I need to log onto computers that I can't install Pass on, which makes it difficult to transcribe my 25 random character password without being able to see what I'm typing in the box.

[danielvandenberg95]

Okay, I took this as a small personal project, and currently have the following. This is a completely personal project, no guarantee that anything of this would make it's way into the app.

I've set up a small Android App that connects to my PC via bluetooth. This uses the method createRfcommSocketToServiceRecord, which creates a secure bluetooth channel. This is said to be secure, but I have not looked into that.

On my PC I've created a virtual COM port for bluetooth devices. The app connects to that virtual COM port. This is a functionality that's baked into Windows, I'm not sure but I'd expect it to also be possible on other OSses.

I've grabbed the first Serial to Keyboard program I could find, https://sourceforge.net/projects/serialporttokey/, and made it listen to that virtual COM port.

I connect my app to my PC, start writing this message, and show that it works by letting the following line be typed by the app:

Hello world!

So what we could make out of this is a system that simply inputs this text onto the PC. Following, some pro's and cons.

Pro's: Nice and easy to implement, as all that has to be programmed is sending Bluetooth data to a COM-port. Should work on any OS, COM-ports are pretty standard. Security shouldn't be an issue as the Bluetooth channel is secured. Yes, programs could listen for the COM-port, but hey, a keylogger is just as big an issue and way more wide-spread.

Con's: Dependant on 3rd party software, the Com2Keyboard stuff. Could of course make our own, doesn't seem too difficult. Relatively difficult to set up on PC. Involves adding a virtual COM-port and manually running a program and so, could also be averted by writing our own software.

// Start talking to myself

I think I will keep on developing that Bluetooth interface, and I might turn it into a service. If I ever get that far, we could set it up so that the Pass app communicates with the Bluetooth service, which could be downloaded separately from the Play store. That way we also don't have to add the Bluetooth permission to the Pass app, since who would expect a password manager to require Bluetooth?

// Stop talking to myself

So, I think it is doable, the question is more one of, do we want this? Or is this a feature that misses the core aim of the Password Store app and bloats it?

[danielvandenberg95]

I've made quite some progress on the aforementioned method, as can be seen in https://github.com/danielvandenberg95/BluetoothToKeyboard. It is now a fully functional system with a Java-based PC-application and a service and intent-receiver on the Android-side. The advantage of how it's set up now is that a simple "share"-button should be able to do the job.

In other words, if we'd add in a button that shares the password in plain text, with the BluetoothToKeyboard app installed on your phone and running on PC, the password will show up on your PC-screen.

I think I should be able to get the BluetoothToKeyboard app to the play-store within a week. I might do so anyways, as it is a fun project to me and has uses beyond just the Password Store. My question now is, do we want a "share as plain-text" button in the Password Store?

[zeapo]

Nice work! For the plain text question, you can use an AES encryption where your PC generates the key, displays it using QR; your app scans the QR code (the key) and encrypts the text then sends it to the PC. Your PC/app can cash the key for few minutes and generates a new one later.

[danielvandenberg95]

I'm assuming that you mean the password being sent in plain-text across Bluetooth? I've read up a bit on the Bluetooth-standards, and it seems that the encryption baked into Bluetooth V2.1 is secure. Currently the app has no support for older versions, and I'm not really planning on putting that in.

https://developer.android.com/reference/android/bluetooth/BluetoothDevice.html#createRfcommSocketToServiceRecord(java.util.UUID)

Use this socket only if an authenticated socket link is possible. Authentication refers to the authentication of the link key to prevent man-in-the-middle type of attacks. For example, for Bluetooth 2.1 devices, if any of the devices does not have an input and output capability or just has the ability to display a numeric key, a secure socket connection is not possible. In such a case, use {#link createInsecureRfcommSocketToServiceRecord}. For more details, refer to the Security Model section 5.2 (vol 3) of Bluetooth Core Specification version 2.1 + EDR.

And from the BCS (Section 5.1.2):

Secure Simple Pairing uses Elliptic Curve Diffie Hellman (ECDH) public key cryptography as a means to thwart passive eavesdropping attacks. ECDH provides a very high degree of strength against passive eavesdropping attacks but it may be subject to MITM attacks, which however, are much harder to perform in practice than the passive eavesdropping attack (see Section 5.1.3, “Man-InThe-Middle Protection,” on page 86).

Sounds secure enough to me...

[zeapo]

Well that's sounds secure enough indeed :)

On Fri, Aug 26, 2016 at 11:46 AM, Daniël van den Berg < notifications@github.com> wrote:

I'm assuming that you mean the password being sent in plain-text across Bluetooth? I've read up a bit on the Bluetooth-standards, and it seems that the encryption baked into Bluetooth V2.1 is secure. Currently the app has no support for older versions, and I'm not really planning on putting that in.

https://developer.android.com/reference/android/bluetooth/ BluetoothDevice.html#createRfcommSocketToServiceRecord(java.util.UUID)

Use this socket only if an authenticated socket link is possible. Authentication refers to the authentication of the link key to prevent man-in-the-middle type of attacks. For example, for Bluetooth 2.1 devices, if any of the devices does not have an input and output capability or just has the ability to display a numeric key, a secure socket connection is not possible. In such a case, use {#link createInsecureRfcommSocketToServiceRecord}. For more details, refer to the Security Model section 5.2 (vol 3) of Bluetooth Core Specification version 2.1 + EDR.

And from the BCS (Section 5.1.2):

Secure Simple Pairing uses Elliptic Curve Diffie Hellman (ECDH) public key cryptography as a means to thwart passive eavesdropping attacks. ECDH provides a very high degree of strength against passive eavesdropping attacks but it may be subject to MITM attacks, which however, are much harder to perform in practice than the passive eavesdropping attack (see Section 5.1.3, “Man-InThe-Middle Protection,” on page 86).

Sounds secure enough to me...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zeapo/Android-Password-Store/issues/184#issuecomment-242683625, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQgBjoNoFpo8m9bfYBx9-fZYwduAJYyks5qjrYPgaJpZM4IfVDN .

Mohamed Zenadi

mail: mohamed@zenadi.com webpage: http://zenadi.com

[danielvandenberg95]

The app I mentioned here-above is now live, and thanks to Pull Request https://github.com/zeapo/Android-Password-Store/pull/213 it's possible to use it in combination with the Password Store.

Is this enough to close both this issue and https://github.com/zeapo/Android-Password-Store/issues/145, or would there be other concrete points that require attention for both of them to be closed?

[zeapo]

Any link to the app? Did you submit it to F-Droid too?

[danielvandenberg95]

I edited in the link to the repository, the link to the app is in the ReadMe. I have briefly looked into F-Droid, but don't fully get what it does yet. I assume it automatically hooks into git-repositories and builds new APK's, but I think that would be off-topic for this issue. I'll probably look into it a bit more tomorrow.

[zeapo]

For F-Droid, it ensures that the builds you get through F-Droid are exactly what you see on github. I think this issue can indeed be closed.

@ashyon Could you test and see if works for you?

[Ajedi32]

The only problem with using an app-based solution for this is that it requires you to download and run a program on the computer you're entering your passwords into. This works for many cases, but doesn't help if, for example, you want to auto-type a password into the computer's login screen, or if you're using a locked-down machine like a Chromebook which doesn't allow you to download and run arbitrary executables. Personally I'd still prefer an InputStick-based solution.

[zidhuss]

I'll close this issue. Discussion can continue in #145.