[FEATURE] Duress PIN for the paranoid

[O35dE]

Preliminaries

There may be situations in which the authorized user is forced to personally enter a PIN to unlock the application, or even consider that this can happen.
Or that this user may feel on the verge of suffering any other form of threat that leads to data exfiltration.
For this kind of situation would be unfeasible to type 3 - 15 times a wrong PIN in order to trigger the optional extra data protection used by Strongbox - but a global Duress PIN triggered in a fast single entry can certainly be an option.

Duress PIN and the extra data protection, that deletes everything within the app after a given number of wrong attempts to unlock it, are as known two very different features.

For the Duress PIN a specific PIN must be entered by the authotized user, which presupposes a deliberate action, who under some form of threat resolves i.e. to delete all data. Then he/she enters this special PIN created previously. For a password manager like Strongbox this resource can be based on the application itself or based on each DB separately.

On the other hand the extra data protection feature results from the unconscious action of an opponent, after the compromise of access to the iPhone, who tries to unlock the application without success, causing the deletion of all data.

These two solutions are naturally not exclusive, on the contrary, they complement each other for improved protection.

My suggestion would be an optional extra Duress PIN feature based on the application, and not just individually by DB as it currently is.

All three options for triggering after the activation of the Duress PIN that are currently supported by Strongbox would remain available and applied to the set of DBs, instead of individually as in the current model:
Open a Dummy Database
Present a Technical Error
Remove Database from Strongbox

By the way this suggested feature can coexist perfectly with all present solutions of the app as explained below.

This suggestion is especially aimed at advanced users who have secure external backups of their DBs.

It would also allow all users to use the Duress PIN feature, because this suggestion would not require the creation of a convenience PIN for the DB, which of course means a reduction in the security applied.

Description

There are three ways to unlock Strongbox:

“None”
Face ID
PIN (alone or + Face ID)

Analyzing each option in conjunction with the current Duress PIN mode, based on each DB, and the extra data erasure protection, we would have:

1- “None” or Face ID:
User may wish to use the Duress PIN feature for each DB, enabling the convenience PIN. The extra protection that allows the deletion of all local data and references to external resources remains disabled, due to the lack of a defined PIN to unlock the app.

2- PIN (alone or + Face ID):
Out of the 999,999 possible combinations in a six-digit PIN, 1 is the correct one and the remaining 999,998 wrong possibilities are covered by the optional extra protection of the application that allows the deletion of everything in the case of compromise of access to the iPhone, after a given number of wrong PIN attempts.
As for the current Duress PIN, based on each DB, it is possible but this naturally requires the creation of a convenience PIN for opening the DB, which would not be an acceptable option for some of the users.

What I suggest would be an additional application-based Duress PIN option, triggered even before unlocking the app, and not individually by DB inside Strongbox as currently.

In this way everyone who wishes can have the Duress PIN function for threat situations activated by the insertion of a pre-defined PIN by the user, without needing to appeal to a convenience PIN and in addition to the current data erasure protection, after a given number of times of the wrong PIN.

The creation of this global app-based Duress PIN is justified by some reasons:

1- The possibility of reducing to just one wrong PIN entry for complete deletion of all the information, which would result in "999,998 Duress PINs”, is naturally unfeasible in practice. But with the global Duress PIN, there is no additional risk of unwanted data loss, because the activation of this feature would depend on a conscious action by the user, typing the Duress PIN created specifically and solely for this purpose.

2- Many users are left without the Duress PIN feature because they will choose not to give up the security of DBs by creating a convenience PIN to have this feature as it is currently applied.

3- The fact of being triggered before unlocking the application brings the advantage of making it much harder for an opponent to exfiltrate the user’s data, differently from the current DB based Duress PIN feature, which is triggered after the unlocking of the app.

Additional context

The security model with the adoption of this suggestion would look like this, depending on the application unlock type chosen by the user:

1- “None” or Face ID:
User may continue using the Duress PIN feature for each DB, enabling the convenience PIN. The extra protection that allows the deletion of all local data and references to external resources and this suggested app-based Duress PIN feature, remain disabled due to the lack of a defined PIN to unlock the app.

2- PIN (alone or + Face ID):
Out of the 999,999 possible PIN combinations to unlock the app, 1 would be the right one, opening it in a normal way, 1 would be the optional global Duress PIN proposed here, to be used by the authorized user in conditions in which he/she feels under serious threat, and the remaining 999,997 would be covered by the optional extra protection of the data, more likely in the case of compromised access to the iPhone by typing of the wrong PIN “n” times. Enabling the suggested application-based Duress PIN would disable the option for the current DB-based feature, in order to prevent the overlapping of the application of similar functions.

I hope the suggestion is clearly formulated (sry for my english) and if it has already been presented I'm sorry, I did a search but didnt find an issue about Duress PIN in these proposed terms.

[strongbox-mark]

We’ll add an Application level duress PIN to our features backlog. Thanks.

[O35dE]

Thanks Mark.