Client: [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 [e-mail]
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
https://github.com/keybase/client/issues/7173#issuecomment-304394050,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACOtDAE0EMo2_6RNWQ5i8t8Hhx3dmgrWks5r90cOgaJpZM4Nn928
.

--
v / r
Robert Klebes
Mobile: [phone]
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: [phone]
https://keybase.io/sporkwitch
https://www.linkedin.com/in/klebes

On October 2, 2017 3:20:55 AM EDT, ralph-tice [e-mail] 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:
https://github.com/keybase/client/issues/7173#issuecomment-333458122

[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?

[sersorrel]

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: [phone]
https://keybase.io/sporkwitch
https://www.linkedin.com/in/klebes

On October 5, 2017 6:31:08 AM EDT, Josh Holland [e-mail] 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)
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:
https://github.com/keybase/client/issues/7173#issuecomment-334426020

[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?