When a service configuration allows it, each token within that service includes an additional authentication secret that can be used by the user to report to the server that they consider themselves to be under duress. A common example might be a criminal forcing a user to open their token in order to perform some kind of transaction.
An app that wants to implement this feature needs to have a mechanism for both registering a duress secret with the server and then selecting the proper secret depending on the user interaction.
There are certain use cases (e.g. if the app uses biometric features available on the smartphone) where this can be hard or impossible to implement but, as mentioned below, it's neither necessary nor reasonable to have the duress feature available in all cases.
The following section discusses the security of this feature as implemented in ZofToken Universal App, which also applies to any other application that uses the ZofToken SDK, and leverages the secret protection functions available in it, by having the user choose both a normal and a duress PIN.
In ZofToken Universal App, the duress feature is entirely transparent from the perspective of the app as neither PIN is stored in the smartphone and the network traffic with the server is indistinguishable from a normal token opening.
Even if a potential attacker, regardless of technical capabilities, had full access to all data in the smartphone and all network traffic, they would be unable to determine if a duress PIN was used or even if a duress PIN has in fact been configured or not.
The server, however, would identify the token request as performed under duress, log it, set the appropriate status for the token and, if configured, call a webhook indicating this event.
There is no technical argument against enabling it as it introduces no additional complexity and would work with any type of integration. However, once enabled, both systems and operating procedures need to be able to handle this situation in a way that makes sense for the organization and the token users.
To understand some of the implications, let’s analyze what could be a classic example: a user is trying to move funds to an external account in a Home Banking system, and when the system checks their token status, it finds that the token has been opened under duress.
At this point the system has a number of options, some of which include (with potential tradeoffs):
There are many other options or variants of the ones presented, but what is clear is that the decision to enable the duress feature (which means that the users should be able to rely on it) is not a simple one. The more limited the group of users involved is (for example, internal IT users or a select group of premium external users) the easier it might be to define a proper procedure to handle such events, while in general enabling it for large, uncontrolled groups would probably be quite difficult.
ZofToken provides this feature as it can be extremely important in certain industries or very secure environments and it can provide an organization with a way to add significant value to certain groups of important users or clients. In any case, we recommend that each organization carefully weighs the opportunities and risks involved before making a decision.
