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 [EMAIL PROTECTED]
