two-person login?

[John Denker]

On 01/29/2008 11:34 AM, The Fungi wrote:

> I don't think it's security theater at all, as long as established
> procedure backs up this implementation in a sane way. For example,
> in my professional life, we use this technique for commiting changes
> to high-priority systems. Procedure is that two security admins
> (each with half of a cryptographic key) collaborate on updates. Sure
> there's still the risk that one is nefarious and will socially
> engineer a back door in while his/her counterpart is watching, but
> that is not so much the risk we are attempting to thwart. The real
> goal is to reinforce policy which requires collaboration between
> administrators for major changes to these important systems.
> 
> Technology can't effectively *force* procedure (ingenious people
> will always find a way around the better mousetrap), but it can help
> remind them how they are expected to interact with systems.

OK, that's clear and helpful.  Thanks.

The point I take away from this is that _procedure_ is primary
and fundamental.  Technology is secondary.  The two-person login 
is technology, and it is only icing on the procedural cake.
 -- If you have a good procedure, the two-person login might help 
  "remind" people to follow the procedure.
 -- If you don't have a good procedure, having a two-person login 
  will not magically create a good procedure.

This also gets back to what I said previously about semantics.  In
the situation The Fungi described, the semantics is clear.  A login
is tantamount to a commit, and the semantics of "commit" is clear.
Both parties make sure they understand the commit before they log
in.  Both parties log in, both parties hang around until the commit 
is complete, then both parties log out and leave.

  One question: If the goal is to have a two-person commit, why not
  implement a two-person commit, rather than using two-person login
  as a proxy?  For years there have been "paperless office" workflow
  systems that require two digital signatures on a purchase order.
  If you're going to use technology to support procedure, IMHO the
  technology should be tied as tightly as possible to the procedure.
  The semantics of login is IMHO very unclear, very open-ended, and
  it takes a lot of hand-waving to tie the "login" technology to the 
  "commit" semantics.

The foregoing makes sense, and is in extreme contrast to the situation
I am faced with, where Joe logs in with the help of Jane, and then
Jane leaves.  Jane has not the slightest control over what Joe does
while logged in.  I don't see a sane procedure here.  It seems Jane 
is signing a blank check.

It wouldn't be so bad if there were a development system separate
from the production system, but there isn't, so Joe spends all day
every day logged into the "high security" production system.  Joe
can commit anything he wishes.  There is no two-party review of the
commit, just two-party review of the login.

Just to rub salt in the wound, they've got it set up so that everybody
uses the "Admin" account.  There are N people who know the first half
of the Admin password, and M people who know the second half.  Besides
being an incredibly lame form of secret-splitting, this has the nasty
property that when Admin logs in, you don't even know who was involved.  
There are M*N/2 possibilities.  There is no accountability anywhere.

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