With the continued rise in home-based and mobile working, the possibility of people being forced to access and potentially modify data during encounters with ne’er-do-wells becomes a genuine security issue. For example, while there haven’t been many cases reported yet, the time will come when the kid lurking in the alley with the switchblade, isn’t just going to want to part you from your smartphone or tablet, but is also going to want to part you from the contents of your bank account, with it. A recent issue of FSTech (http://www.fstech.co.uk/), a UK-based financial services technology magazine, stated that banks are concerned about the lack of uptake of mobile banking solutions; my guess is that the duress situation, is one of the reasons people are averse to doing their banking “on the go”. There are actually three categories of duress, these being:
- local: a threat to your person, which will be exercised unless you do what you are told (eg: a gun to your head)
- divorced: a threat to your family or other people you personally care about (and who are in a different location), which will be exercised unless you do what you are told (eg: a gun to your wife’s head)
- remote: a threat to individuals unknown to you, which will be carried out unless you do what you are told (eg: a bomb in a populated area).
Taking this into account, it’s possible that a well-designed system which authenticates users based on a username and password would require up to 4 passwords per user – one for legitimate login in a normal situation, and three more, one for each type of duress! All these different categories may be required, as different workflow actions would be desirable based on the nature of the duress; although depending on differences in actions between duress types, some categories may be collapsible. For example: Local duress:
- log me in, increase the level of user activity logging on my account, start signing logs to ensure evidential integrity (if not done already)
- take snapshots of databases to which I have access, my home directory, etc, such that activities I perform can be rolled back
- alert security or law enforcement personnel as to my location and the fact I’m in peril, request their intervention
Divorced duress:
- log me in, increase the level of user activity logging on my account, start signing logs to ensure evidential integrity (if not done already)
- take snapshots of databases to which I have access, my home directory, etc, such that activities I perform can be rolled back
- alert security or law enforcement personnel to my location and the fact that folk I care about are in peril, ensure appropriate authorities are informed, but remain on standby
Remote duress:
- log me in, increase level of user activity logging on my account, start signing logs if not done already
- start backups / snapshots of databases to which I have access, my home directory, etc, such that activities I perform can be rolled back
- alert security or law enforcement personnel to the fact that there is a threat to some remote location which can’t be disclosed right now, ensure appropriate authorities are informed, and remain on standby
…or whatever is considered appropriate for the situation, by organisational policy; in the case of a bank being alerted of a duress situation by a customer, transactions between institutions across the SWIFT network would need to be flagged as being allowed to proceed, but in such a manner that they could be reversed once the situation is resolved. While tokens, biometrics etc can all be employed to authenticate individuals to systems, only a password – or some other secret known only to the legitimate user, such as an order in which to press fingers to a biometric reader or a PIN to type into a token – can be substituted for an equivalent but different password to indicate duress, in a manner which cannot be observed and identified by whomever is present and causing the duress. In this respect, in a classic “defence in depth” approach to security, a duress password is “the last line of defence” available to an imperiled user. With access to data and services now being available to a typical individual anywhere there is a 3G signal, the likelihood of users finding themselves under duress at times when they have the ability to connect to systems and engage in transactions will only increase. In terms of implementation, there are three primary places where changes would need to be made in order to implement a duress system:
- The user directory schema would need to be extended to include duress passwords
- the authentication system itself would need to be extended to support entry and change of duress passwords, as well as requiring a command / control interface to the user transaction systems in order to implement logging and snapshot / rollback changes as required
- an out of band alerting system will need to be either installed or updated, to meaningfully communicate duress details
Duress password expiry is an interesting policy issue; I would expect a password would only be required to be changed after use if at all, as its use will hopefully be a very rare event indeed.
Related articles
- Passwords Go Bye Bye By 2017? (scientificamerican.com)
