Async support for two factor pin verification

[normanr]

It would be nice to be able to do pin verification as part of a NodeRed flow. It would also make it so that the SmartNORA service doesn't have to store secondary verification pins.

Some things that could be implemented with async verification of pin:

• multiple pins - one for each person
• duress pins - unlocks/disarms, but also silently activates an alarm
• pins that only work at certain times on certain days
• rolling codes - like TOTP (but with a long duration like 1 day)
• single use pins - like HOTP (might be useful for contractors)

[andrei-tatar]

I was thinking at adding the option of generating and sending (via push notification) a random pin when a pin verification is required. This would keep rolling the pin on each use.
Wasn't sure if it's very useful and requires access to a phone with notifications enabled each time pin verification is required.

I will try to evaluate how much effort would be adding Async pin support. Even the async commands have a very low usage.

multiple pins - one for each person

Technically there's no way to know how many persons are using a google home device. That information is not shared by Google via the Smart Home SDK. Also, there's no way of knowing which person issued a command.

[normanr]

I was thinking at adding the option of generating and sending (via push notification) a random pin when a pin verification is required. This would keep rolling the pin on each use. Wasn't sure if it's very useful and requires access to a phone with notifications enabled each time pin verification is required.

I will try to evaluate how much effort would be adding Async pin support. Even the async commands have a very low usage.

Yea, I think the nice thing about adding Async support is that things like random pins via notification then become something that is configured in Node Red flows, and there doesn't need to be any special support in smartnora (besides the async support).

multiple pins - one for each person

Technically there's no way to know how many persons are using a google home device. That information is not shared by Google via the Smart Home SDK. Also, there's no way of knowing which person issued a command.

Yea, I didn't mean with speaker/person detection, just that eg: Alice would unlock with 1234, and Bob with 5678 so that you could track who did the unlock.

[normanr]

I just discovered that the security system node has had support for async commands from the begining (#80), but I have not actually tested it out to see if the pin is verified before the async msg is sent from the device node.

From reading the code it looks like for local execution, secondary verification is skipped for async commands (but security systems do not support local execution), and I've just assumed that secondary verification can not be skipped for cloud async commands. It looks like only camera devices can return async results, so I assumed that the server must check the secondary verification before writing the command to the database, or updating the device state.

[andrei-tatar]

@normanr as far as I remember, from the Google docs, no commands are issued via "local execution path" for secondary verification devices.

Async commands isn't related necessarily to local execution path. It's more about the fact that the request that comes from google (via cloud/local execution) is blocked until the node-red handler from the flow is invoked. This allows to return custom error codes or have custom command handling in the node-red logic.

[normanr]

Yea, I don't expect local execution to work for devices that require secondary verification.

Mostly I was hoping that (instead of doing the secondary verification in the cloud before triggering the async flow in node red) there could be an option to "do secondary verification as part of the async command execution" (eg: setting Two Factor to Async or something similar). Basically it would just disable the secondary verification step at the cloud layer, and pass the challenge data as part of the async message sent in to the node red flow. The node red flow would be responsible for checking the challenge ack/pin and generating the challengeNeeded pinNeeded/challengeFailedPinNeeded as needed.