Every token within the ZofToken app is protected by a 4-digit PIN that the user needs to enter before opening it or performing any other action. If the service configuration allows it, the user can select an additional, different 4-digit PIN that they can use to open their token in any situation when 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.
Using the duress function is entirely transparent from the perspective of the ZofToken app as neither PIN is stored in the phone 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 phone and all network traffic, they would be unable to determine if a duress PIN was used or even if a duress PIN has actually been configured.
The ZofToken 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 function (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 function as it can be extremely important in very secure environments and it can provide a way to add significant value to certain groups of important users or clients, but we recommend that each organization carefully weighs the opportunities and risks involved before making a decision.