Masking password input with backchannel event

[enessoylu]

If you send the following event to WebChat through the backchannel, the input box will become a password input until you send a message.

Event:

{
    name: 'inputTypeChange',
    type: 'event',
    value: 'password'
}

Demo:

[billba]

Generally we encourage bot developers not to use bots for passwords, PII, and other secure data. Although Web Chat and Direct Line are secure, sending things like passwords through the same channel as the rest of the text tends to lead to bad situations. You wouldn't want passwords in LUIS utterances, for example, which are often made available widely to people in an organization.

But in this PR is a hint of a way forward. Just as you send a special type of activity from the server to initiate a password, you could also send one to the server with the password. This would allow you to create a secure pathway separate from the normal text pathway. This would have to follow all the best practices for passwords.

Do other channels have special affordances for passwords?

I would think of the server->client activity as an extension of Message indicating that the current message is requesting a password. But on the way back I'd either use a new password Activity type or an event Activity with name "password".

(I'd want an actual security expert to look at this and chime in.)

Some notes about your implementation:

• Instead of a broad notion of "input types" I'd just make this about passwords. If it needs to be generalized later, we'll do it later.
• Instead of hacking sendMessage I'd add a sendPassword method.
• In terms of UX state I'd follow the lead of Suggested Actions, they're both similarly modal

@compulim @vishwacsena I think this idea is worth considering.

[billba]

(Also, it’s better to raise an issue than go straight to a PR.)

[compulim]

I understand the need to send secret over. A few things on UX:

1. How about sending secrets thru an Adaptive Card (or similar UI)?

• Separate UI make the user feel more secure than the send box
• We could hide/delete the UI after the secrets is sent

2. The user should be notified, before typing, that what they send will be masked
3. How about if the last message was activated by speech? The microphone icon will be pushed by default, need to handle that

We could use jsencrypt and use a public/private key to encrypt the data, just in case if they are not secure enough

[billba]

re: adaptive cards, maybe. Those still send messages, but the actual password wouldn't be in the text field, which is good. We should drill into this some more and see if this is above the bar. Essentially we are trying to predict how people will typically write bots, and provide a pathway that makes it as likely as possible that passwords will be handled securely.

In terms of UX, we can all have opinions, but ultimately the the only way to know what users will prefer is user testing. I'd put an Adaptive Cards password form up against a version of this with clearer chrome, e.g. the input field says "enter your password here" with a standard "show password" checkbox.

I don't think we need further encryption - Direct Line is https - but let's not you and I just guess. We should bring in someone who knows password security really well.

tl;dr let's decide whether some version of this feature makes sense and is worth investing in. If so, let's bring in some experts to decide how to proceed.

[compulim]

The feature did not go into Direct Line as a standard event.

Until we get this event into Direct Line, I prefer it to be done as a sample so people can "opt-in".

You can look at one of the samples that customize activity. And implementing a new activity that render a password box.

Since the new sample would be very different from this PR, I am closing this one.

Please feel free to submit another PR for this work.

[compulim]

This is the tracking issue for the sample, #1413.