Open selivan opened 7 years ago
I think this feature is a much needed one to make the application much more secure.
Hi, I had the same idea for a different password app, but the same principles apply. I thought Id just chime in with the problems that I faced:
1 and 2 are easy, but I'd like to see some discussion around 3
@OverlordAlex
P.S. Sketches made with https://sketch.io/, and it doesn't seem that I am going to have a brilliant designer career :)
Something like that:
@iskrant Those are some nice mockups!
Something to consider - would you want to be able to create a new password entry this way? This adds complexity, but it's also nice when creating an account on a new site to simply do it all in one flow.
On the point of including a minimal keyboard - I don't think this is acceptable. What if the user is using a Cyrillic keyboard to enter their unlock password? We would have to either have localisations or restrictions on passwords - bleh. We're going to have to show a keyboard picker at the end of the flow in order to return the user to their default, so if we show it at the beginning we can then use it for the unlock/searching.
Thank U!
Use the keyboard switch looks like a logical solution, If there is no possibility to display a full application-keyboard (such as a hackers keyboard or a.i. keyboard) inside keepass keyboard application.
The ability to create a new password directly from this application would be cool!
We're going to have to show a keyboard picker at the end of the flow in order to return the user to their default, so if we show it at the beginning we can then use it for the unlock/searching.
Please explain indetail what do you mean, I am not sure I completely understand
It's not possible (on a non-rooted android device) to change the users keyboard from code. This is to prevent malware silently changing the users keyboard to a keylogger.
Once the user has selected the password entity from the database, and it has been entered into the text entry box by the keepassdroid keyboard, they need to switch back to their default keyboard. Since we can't do it from within our code, we will have to show an keyboard picker (IME chooser).
However, we need a keyboard in the meantime so that the user can unlock the database (if needed), and so that they can search for the correct password entry. Since we will have to show the picker at the end of the flow, we may as well show it at the beginning (or when its first required).
This means that we wouldn't have to include a basic keyboard as part of the keepassdroid keyboard.
This all hinges on how android handles the flow - if we have a popup in the foreground with the keepassdroid keyboard, what happens when we switch keyboards? Does it kill the popup?
I really just want to avoid having a keyboard as part of the keepassdroid part, as all that work has been done for us.
I'll try throw together a prototype this weekend to see if I'm talking junk or if its actually viable.
Now this problem can be solved with new Autofill API for Android 8.0: #217
API level 26 also added the IME_FLAG_NO_PERSONALIZED_LEARNING API. Enabling this would have the Incognito mode of the keyboard in order to avoid recording typing history and user dictionary data on the keyboard while the user is doing a certain task in the app.
How does LastPass achieve it's direct fill option with the screen overlay?
Transferring passwords though clipboard is insecure by design: any other application can steal it.
I suggest to make KeePassDroid a keyboard application: when user need to enter password safely, he changes default keyboard to KeePassDriod, unlocks database if not unlocked already and selects the entry to type password. Then KeePassDroid switches keyboard back to default one.
That way is not convenient as copying to clipboard, but it's really secure.