1

Suppose I'm designing a system where I want to make sure that no single user who goes rogue can commit a malicious action. (I'm ducking the question of how two or more users could collude.) And I assume the machine is physically secure.

One possibility would be to require that the admin logon password be split between two people -- one person types in the first 10 characters, the second person types in the second 10 characters. Account protocol dictates that any user who has a portion of the password can be responsible for actions committed from that account -- i.e., once the pair log in, both of them have to stay there and babysit each other until they log off from the account. (Because it's annoying to require two people to be present, the overall architecture should be designed to require the minimum number of actions to be carried out from this privileged account, which is good design anyway.)

One problem is that this is brittle -- if one user becomes available, the whole account is inaccessible.

So, instead, the operating system can split the administrator account between 3 usernames, each with their own username and password. The admin login screen presents 2 username/password forms, and to access the admin account, 2 out of 3 of those users have to enter their credentials. This retains the property that no single user going rogue can access the admin account, but it also means that the account can still be accessed if 1 of the 3 users is unavailable.

This seems like a useful feature. Does it have a name? Does any operating system implement anything like this?

(I realize that things get complicated if, for example, you have an encrypted folder on the hard disk, which most systems handle by encrypting the folder in a way that incorporates the user's password as part of the decryption key. If you want to make sure that the encrypted folder can be decrypted whenever 2 out of 3 users log in, but that no user by themselves can decrypt the folder with their password even if they have access to the data on the hard disk, then you need to encrypt it using a secret-sharing scheme such that 2 out of 3 secrets are enough to decrypt it but 1 is not. This is, however, still doable.)

2

What you describe is similar to Shamir's Secret Sharing, in that you need a quorum in order to operate.

However, in you case you are dealing with authorization of admin actions, rather than secret messages. If designing a system around this concept, I wouldn't generally design it that way, but do it as 'tasks' that get queued and need approval from N users.

Suppose Admin1 wants to delete the account of user55. This is an action that requires multiuser approval, so it gets logged and "Deletion of user55" is in pending status. When Admin2 logs into the system later (2 minutes later or next week, it doesn't matter), it sees that the pending of user55 is and approves it since it knows he has left the company. It is at that point that the real action would take place. This would also allow you to set different criteria depending on the sensitivity of the action (like a given action only needs an admin but another requires 5) or the exact role (a junior admin could be allowed to do some things, but certain other would require approval from two seniors).

There are bank accounts that already work this way, where there are several joint owners and the actions need to be approved by all of them. It is quite similar to the way StackExchange works, too.

  • This would be useful but it would require rewriting all apps to be compatible with the "put action into pending queue, then approve later" protocol. What I'm describing would only require a change at the OS logon level, while remaining backward-compatible with any other apps that work for that OS. (Also, the "queue this action" design doesn't work if a user needs to see the results of one action before doing the next one. Sometimes you need to log on as admin and mess around to troubleshoot.) – Bennett Oct 9 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.