[Basics] Two-factor authentication

It's also called token based authentication. It sounds like something new, but we have been using it for ages. Virtually all ATMs use two-factor authentication for debit cards.

What is two-factor authentication?
Before I explain, what two-factor authentication is, let me list the three possible way to authenticate a person or a thing based on the following criteria:
- what you know (e.g. password, pin)
- what you have (e.g. debit card, mobile phone, USB stick token)
- what you are (e.g. fingerprint, iris, face)

Most systems reply only on one of the above three factors to authenticate a user. For example, a bank website asks you only for your username and password (what you know) to login to their site. The idea behind two-factor authentication is simple; use two of the above factors to authenticate a user.

Examples of two-factor authentication
As mentioned above, debit cards on ATMs use two factor authentication:
- Debit card (what you have)
- 4 digit PIN (what you know)

Google supports mobile based two factor authentication. You use your regular username and password (what you know) along with the code sent to your mobile phone (what you have).
- mobile phone (what you have)
- username and password (what you know)

RSA SecurID supports two factor authentication.
- token generated either from a hardware device (USB dongle) or a software app. (what you have)
- any of the other two factors listed above

Most common form of  two factor authentication is to use a token and a username/password. So, it is important to safeguard tokens to have a secure two factor authentication system. Tokens are basically OTPs.

Where can an attacker exploit in a token based authentication flow?
- token infrastructure
- token vendor
- token itself
- client using the token (mostly attackers exploit this as clients are usally the weakest link the whole flow)

Example attacks on token based authentication systems
- Attack on RSA SecurID (attacking token vendor)
- Differential power analysis attacks to recover tokens/keys (attacking token itself) - recovering DES/AES keys, recovering smartcard keys
- malwares to steal tokens from clients (attacking clients) - Zeus trojan in 2007-2009

There are security measures that you can take in order to defend against above types of attacks.

[Oracle] Proxy Authentication

You are the DBA of your organisation managing a cluster of Oracle databases. You want to give full access to a schema (say hr) to multiple database users (say bob and alice). How can you do it?

One approach is to give schema name and password to the users. Do you see any problem with that approach? I can think of at least a few:
1. Accountability - multiple users using the same username/password makes tracing actions to database users impossible.
2. Security - shared password is more vulnerable to exposure risks.
3. Revocation - in order to revoke access to the hr schema, you need to change the password of hr user.

Another approach would be to grant system privileges to bob and alice so that they can do anything on the hr schema. However, this does not follow the principle of least privileges and is prone to misuse as users are given more privileges than they require to do the job. Therefore, it is not a good idea to grant system privileges. In fact, as a rule of thumb, system privileges should be granted sparingly in order to improve security.

An improved approach would be to grant all privileges on the hr schema to bob and alice. This requires granting object privileges on each object in hr schema. Managing many object privileges is a nightmare. Further, this does not allow to create new objects in the hr schema. Therefore, this solution also has limitations.

So, what can we do about it? Having identified the above limitations, Oracle actually introduced what is called proxy authentication for such use cases. You simply grant proxy authentication to the users. The following toy script shows how to:  (You can also further restrict access to the schema by specifying what roles can be used during the proxy session. For simplicity, I am omitting such fine tuning here.)


SQL> conn / as sysdba
Connected.

SQL> alter user hr grant connect through bob;
User altered.
SQL> alter user hr grant connect through alice;
User altered.

SQL> 
SQL> conn hr
Password:
SQL> create table emp(name varchar2(100), sal int);
Table created.

SQL> insert into emp values ('tim', 125000);
1 row created.
SQL> insert into emp values ('eve', 150000);
1 row created.

SQL> -- bob connecting as proxy user

SQL> conn bob[hr]

Password:

SQL> select sys_context('userenv', 'current_user') from dual;

SYS_CONTEXT('USERENV','CURRENT_USER')

-------------------------------------

HR

SQL> select sys_context('userenv', 'proxy_user') from dual;

SYS_CONTEXT('USERENV','PROXY_USER')

-----------------------------------

BOB

SQL> -- bob can do anything on hr schema

SQL> select * from hr.emp;

NAME      SAL

------------------

tim       125000

eve       150000

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