Dave's Bit Bucket

Mobile / Home-based Computing and Duress

With the continued rise in home-based and mobile working, the possibility of staff being forced to access and potentially modify data by suitably-armed ne'er-do-wells becomes a genuine - if niche - security issue.

I was chatting to a pal on Friday evening who has an Armed Forces background, about duress situations and passwords which might be required.

It turns out that 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 non-duress situation, and three more, one for each type of duress!

It's entirely possible that all these different categories would be required, as different actions would be desirable based on the nature of the duress. For instance:

Local 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
• alert security personnel as to my location and the fact I'm in peril, request their intervention

Divorced 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
• alert security personnel to the fact that folk I care about are in peril, contact appropriate authorities 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
• alert security personnel to the fact that there is a threat to some remote location which can't be disclosed right now, contact appropriate authorities and remain on standby

...or whatever is considered appropriate for the situation, by organisational policy. If it is not considered useful to make a fine-grained characterisation of the duress in order to be able to instruct authorities, the different situations above can be collapsed somewhat.

To re-iterate, in these days of remote working and given the nature of data which many folk have access to, the need for a duress password (or other duress-alerting) system is becoming increasingly important. In an infrastructure designed around "Defence in Depth" principles, a duress password is not only the "last line of defence" for an imperiled legitimate user, but it does for them what smartcards, shared-secret tokens, etc cannot, by enabling them to surreptitiously raise a useful alert.

In fact, for some kinds of protectively-marked data, it's fair to say "if a user's physical location isn't inside a suitable building with appropriate authenticating physical access controls and on-site security personnel, then it's in battlespace".

I can see various points in Sun products at which a duress capability could be inserted; an LDAP server would be the most obvious place (as both normal and duress passwords would be stored there, and the LDAP server would be the natural point at which to record the use of a duress password, approve access as though the password was correct, and raise an alert to some workflow system which would do all the audit and snapshot-wrangling). Changes in account maintenance software would be required, in order to be able to change both normal and duress passwords, but otherwise the surrounding impact would be small provided LDAP was used for pretty much all user authentication (which, frequently, is the case)...

(2007-08-30 10:04:07.0) Permalink Comments [0]

Why a Passport can't be treated as a definitive proof of identity...

It's "that time of the decade, again" when I need to renew my British passport.

I'm relieved to see (from here) that I don't need to have a mad dash round to find someone who can put a declaration and signature on the back of my photograph (in suitably microscopic writing) to the effect that they assert that I'm me - while my ponytail went the way of the scissors the better part of a decade ago and I'm a little plumper around the cheekbones than I was, I'm still recognisably "me" in my old passport photo.

This led me to think about the bootstrapping mechanism for new passports, and in particular, how folk are deemed worthy of being able to assert to the Passport Office that someone is genuinely who they claim to be, to the Passport Office's satisfaction.

The list of approved counter-signatories can be found at http://www.passport.gov.uk/passport_countersign.asp

From the large list presented - and notwithstanding the extending clause of "someone of similar standing in the community" - I suspect that the average person wouldn't have too much trouble finding someone who could be duped or bribed into providing a false assertion of identity for the Passport Office...

(2007-08-30 08:14:27.0) Permalink Comments [1]

When "Open" is nothing of the sort...

Startling reading on Microsoft OOXML internals, with worked examples, here.

If this is entirely correct, I think I've just seen my first example of "an implementation of a would-be open standard which can't be interoperated with".

Boggle.

(2007-08-30 07:49:18.0) Permalink Comments [0]