two-person login?

[Ian G]

John Denker wrote:
> We need to talk about threat models:
>   a) The purveyors of the system in question don't have any clue
>    as to what their threat model is.  I conjecture that they might
>    be motivated by the non-apt analogies itemized above.
>   b) In the system in question, there are myriad reasons why Joe
>    would need to log in.  If Joe wanted to do something nefarious,
>    it would take him less than a second to come up with a seemingly
>    non-nefarious pretext.  When the approver approves Joe's login,
>    the approver has no idea what the consequences of that approval
>    will be.  The two-person login requires the approver to be
>    present at login time, but does not require the approver to
>    remain present, let alone take responsibility what Joe does 
>    after login.
>   c) The only threat model I can come up with is the case where
>    Joe's password has been compromised, and nobody else's has.
>    Two-person login would provide an extra layer of security
>    in this case.  This threat is real, but there are other ways
>    of dealing with this threat (e.g. two-factor authentication)
>    ... so this seems like quite a lame justification for the
>    two-person login.
>   d) Or have I overlooked something?


OK, putting on the devil's advocate hat & cape here...

Consider the latest case with SocGen where a trader goes 
rogue (so the news has it at least).  One might argue that 
the system you are talking about provides a control over that.


>>From the foregoing, you might conclude that the two-person login
> system is worthless security theater ... but harmless security
> theater, and therefore not worth worrying about either way.


There is the possibility of compliance controls.  In audits 
and sarbanes-oxley and other things there is frequent talk 
of dual control and 4 eyes principle.  Now, it could be that 
these points can be "easily" covered by employing a system 
that "enforces" this.  Often, auditors will be convinced if 
they can see something in place, and not feel the need to 
audit the system itself.  The auditor's job is done when he 
can safely say "management has put in place procedures..." 
and the system you mention meets that protocol in words at 
least.


> But the plot thickens.  The purveyors have implemented two-person
> login in a way that manifestly /reduces/ security.  Details 
> available on request.
> 
> So now I throw it open for discussion.  Is there any significant
> value in two-person login?  That is, can you identify any threat 
> that is alleviated by two-person login, that is not more wisely 
> alleviated in some other way?


It might be useful for management to decree that all juniors 
must work with a senior watching over.  Also e.g.,  critical 
systems where two systems administrators work together.  In 
linux there is a program called screen(1) that allows two 
sysadms to share the same screen and type together.  This 
has a lot of value when "two minds are better than one." 
But, yes, this is not quite what you are describing.

Also, it might be a control to enforce other procedures.  If 
the sysadm is given the controls to some departmental 
system, then instead of just waltzing in and playing with 
it, he has to ask the non-techie boss, who then asks what 
the story is.  This way she can know that the appropriate 
procedures are in place, such as notification to users.

It's far easier to figure out what the sysadm is up to if he 
is forced to have a conversation every time he wants to log 
in...  this addresses your point b above, in that it now 
clearly labels any disaster as something the sysadm should 
have told the boss about before, instead of leaving it in 
the murky area of "of course I intended to scrub the disks, 
that's my job!"


> If so, is there any advice you can give on how to do this right?  
> Any DOs and DON"Ts?


I'd expect a proper physical token to be the manager's login 
mechanism.  If it was a password he typed in there would be 
too much incentive to share the password.

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com