[Android] POTENTIAL VULNERABILITY: Paper key proofs use normal TextView, not Password

[sporkwitch]

The TextView used for entering a paper key to prove a device should be configured as a password field to prevent non-malicious keyboard applications from including the pattern of words in their completion history and statistics. This poses a potential compromise of the paper key, especially with the remote storage of patterns that many keyboards do.

[cjb]

We've thought about this too, and decided to go with leaving completion on for UX reasons -- typing the whole paper key without autocorrect is really hard -- but we can revisit it.

If there's a way to disable use of third-party keyboards for this form, while allowing an OS-provided keyboard to autocomplete, that would probably be best for us..

[sporkwitch]

I'm not aware of a method off the top of my head, but I'm also not a particularly experienced Android dev (if I were, i'd fork k9mail and openkeychain to fix the regressions he deliberately introduced, haha).

I thought about the usability as well, my personal leaning is in favor of security; as annoying as it might be to reenter it, it's not something you enter often, but the damage from potential compromise is extensive. That's just my evaluation, but I tend to be willing to sacrifice a little usability if I judge security to justify it.

I would request opening this to the community for discussion; I suspect most users will use other methods of proof anyway, so this only affects the particular case of paper key proofs.

[cjb]

Sure. Happy to leave this issue open to hear more about what our users prefer.

I think you could personally just avoid ever entering a paper key on a phone. You can always use a real device instead of a paper key.

[sporkwitch]

Generally, but in the event it's necessary, there's an issue. No current arm builds, but the Android client does work on Chromebook.

…

On Fri, May 26, 2017 at 5:41 PM, Chris Ball ***@***.***> wrote: Sure. Happy to leave this issue open to hear more about what our users prefer. I think you could personally just avoid ever entering a paper key on a phone. You can always use a real device instead of a paper key. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7173 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACOtDAE0EMo2_6RNWQ5i8t8Hhx3dmgrWks5r90cOgaJpZM4Nn928> .

-- v / r Robert Klebes Mobile: 571-492-8639 https://keybase.io/sporkwitch https://www.linkedin.com/in/klebes

[sporkwitch]

@cjb

Just occurred to me the right way to solve this without sacrificing user experience. Using textVisiblePassword as the input type should prevent autocompletion from recording, learning, or offering suggestions (as it's a password field) while still keeping the characters visible. It is also possible to toggle between textPassword and textVisiblePassword with a button or checkbox.

We solve the security issue, while still avoiding the nightmare of figuring out where you made that typo. Seems like an excellent compromise, in my opinion.

[cjb]

@sporkwitch Ah, sorry I was unclear -- we actually want the autocompletion for UX reasons. Will think about this though!

[sporkwitch]

Yeah, i got ahead of myself and caught that after rereading the thread myself.

[ralph-tice]

Default should be a textVisiblePassword and a checkbox to swap it out for an autocompletable field.

I propose an improved UX offering instruction on the risk of enabling autocompletion.

WDYT?

[sporkwitch]

For what my opinion is worth, I think that would make for a very reasonable compromise. v / r Robert Klebes Mobile: 571-492-8639 https://keybase.io/sporkwitch https://www.linkedin.com/in/klebes

…

On October 2, 2017 3:20:55 AM EDT, ralph-tice ***@***.***> wrote: Default should be a textVisiblePassword and a checkbox to swap it out for an autocompletable field. I propose an improved UX offering instruction on the risk of enabling autocompletion. WDYT? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #7173 (comment)

[cjb]

My sense would be that this sounds confusing and offputting to non-technical users, which usually makes things a no-go for us. If you're explaining, you're losing. :/ Thanks for the suggestion though.

[ralph-tice]

I read your reply as:

Explaining things to non-technical users is confusing and offputting

which is itself confusing and offputting to me.

Given that stance, another potential solution would be to implement our own client side autocompletion in a masked field.

Another option would be an A/B test to make this decision data-driven.

Can I help with either of those?

[keysmashes]

Given that the list of possible words in a paper key is known, the Keybase app should also be able to do a much better job of autocompletion than a keyboard app.

Alternatively, you could use IME_FLAG_NO_PERSONALIZED_LEARNING (docs) to instruct keyboards to avoid learning from text entered there.

[sporkwitch]

Limiting the range of autocomplete suggestions would degrade security by further limiting search space (though if the code for paper keys is public, I suppose that search space is already known, so that may be moot). That flag seems ideal; legitimate keyboards would obey it and malicious ones are saving and sending back your keystrokes anyway. v / r Robert Klebes Mobile: 571-492-8639 https://keybase.io/sporkwitch https://www.linkedin.com/in/klebes

…

On October 5, 2017 6:31:08 AM EDT, Josh Holland ***@***.***> wrote: Given that the list of possible words in a paper key is known, the Keybase app should also be able to do a much better job of autocompletion than a keyboard app. Alternatively, you could use `IME_FLAG_NO_PERSONALIZED_LEARNING` ([docs](https://developer.android.com/reference/android/view/inputmethod/EditorInfo.html#IME_FLAG_NO_PERSONALIZED_LEARNING)) to instruct keyboards to avoid learning from text entered there. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #7173 (comment)

[ax3l]

I can only second the OP's concerns.

I recently entered my paper key into the app. When I opened an email afterwards and started the first, publicly known, word of my key the suggestion of my keyboard (swift; enabled languages: en & de) suggested me properly every single word of my paper key without typing anything else.

[TravisWhitehead]

Sure. Happy to leave this issue open to hear more about what our users prefer.

My preference is that y'all use the IME_FLAG_NO_PERSONALIZED_LEARNING flag mentioned above. This seems like an ideal solution considering it:

• doesn't disable autocomplete (for ease of typing in paper keys)
• prevents data about paper keys from being recorded (when the IME respects this flag).

@cjb I know this issue is a bit old; have y'all revisited this at all and considered this solution to this possible key leakage?