Real-world access control - all or nothing

This blog post is inspired from a poster appeared in this year's CERIAS symposium. Up until I saw this poster, I had not put much thoughts into real-world access control for general use cases such as accessing a bank account, mobile phone service account, electricity service account, etc. Specially on the issues of separation of duty and principle of least privilege. In this post I will be focusing on the second issue of least privilege. In general terms, the principal of least privilege means that a user should be allowed to access (read/write/update/delete) only those resources required for the job at hand. If a user needs to read only a specific resource R1, it is a bad idea to grant read access to all resources, and worse to grant write access also.

Let's take a simple example from MySQL database app.

The database has three users; root, user_ro and user_rw. As we know, root can do anything to the database. user_ro and user_rw have the following grants:

GRANT SELECT ON db1.* TO 'user_ro'@'localhost';
GRANT SELECT, INSERT, DELETE, UPDATE ON db1.* TO 'user_rw'@'localhost';

So, user_ro can only read tables from db1 and user_rw can read/write to tables from db1. In a typical database app, when you want to allow users to read only data from tables (i.e. reading a forum without login for example), you connect to the database using user_ro; when you want to allow users to write also, you connect to the database using user_rw. And when you want to perform administrative tasks you connect as root. Why do we not use one single database account to do all this? The answer is the principle of least privilege. What does it buy you? If your system is compromised, the amount damage caused can be controlled by having different accounts with different privileges. For example, if the application is compromised while user_ro is used to connect to the database, the attacker can only read the database, and nothing else. (The granularity of the application of the principal of least privilege and the practical management privileges is another issue that is worth a separate blog post. So, I will not go into that in this post.) 

Now let's consider the access control in real-world applications.

I am sure most of us have online back accounts. We have one username and one password to connect to the web site and do whatever operation we want on our account. In other words, one username and one password provide all or nothing access. However, after successful log in, we do not perform all available tasks each time we log into our bank account; in fact, we don't use more than 90% of the operations that we are authorized to do. Let's simplify the operations and break them down to two operations (read only, read & write) for the sake of simplicity:


(a) read balances, credit card transactions, etc.
(b) transfer money (for example from checking to saving, checking to credit card, pay bills, transfer to an external account, etc.)

It is the usual practice to perform (a) much more often over (b). That is, users will be performing read-only operations most of the time.

From the security point of view, a better authentication mechanism would be to associate each user with two username/password accounts. For example, user Bob has two accounts bob_r/pw_r and bob_w/pw_w. bob_r/pw_r allows Bob to do (a) and bob_w/pw_w allows Bob to do (b).

If this is more secure, why banks today don't implement such a scheme? The answer is usability [3] and manageability. Managing one password is already a burden. Managing several passwords is going to be a nightmare for both users and banks. Even though password based authentication is known to be vulnerable [2, 4], it does not appear to be replaced by any other alternative approach any time soon [1]. As we colloquially say we are stuck with passwords! So, with this assumption of legacy passwords continuing to be in existence, can we come up with a better password based approach to provide principal of least privilege in real life applications?

The ideal approach should use only one username and one password to provide the same level of usability as earlier. However, it appears that it is not possible to use the same username/password to provide the separation of duty with least privileges and provide better security against attackers.

One preliminary approach would be to order the privileges in the increasing order, in our case (a), then (b), and always login the user with the least privilege (a). In order to perform an operation that requires a higher privilege, the service provider (bank) should ask the user something that he/she knows and but that information should not be readily derivable from users initial login password. Such a solution works if users majority of time are doing only (a), but introduces usability issues if  users frequently want to do (b). Further, if there are more levels of privileges, it further complicates the situation. Do you have a better idea?

I am interested to know if there are any research that has already attempted to solve this issue using password based authentication only. Please share if you know any such work.

 

[1] The Quest to Replace Passwords
[2] Password Security: A Case History
[3] Users are not the enemy, CACM
[4] Foiling the Cracker