Two Cookies Can Make You Fat But They Are Not Two-Factor Authentication
By Mark Wilcox - CTO - Oracle Consulting Security-Oracle on Oct 08, 2008
This post is inspired by a conversation I had with one of our customers. They have a team responsible for customer facing revenue applications and of course that team is trying to make sure they have strong security.
On the good news side - the team knows they need "two-factor" authentication. A factor is normally based on the concept of something you know (aka a password or answer to a security question) or something you have (digital certificate, fingerprint).
However, apparently it's the cool thing to do for certain web-sites to have "dual-cookies". One is persistent to store simple profile information (like what page do you want to go to when you login) - nothing secure. The other is your session cookie. And the perception in this team (and maybe they learned it from some magazine/conference) is that this is a type of two-factor authentication. And in particular they thought this would help protect access from "new unknown machines".
Any security professional knows this is not the case. Session cookies are often used to enable Web-based SSO. The persistent cookie is really just used to help manage profile information that can't be stored elsewhere. And just because there are two-cookies it does not make it two-factor authentication.
However, the better way to solve this problem isn't two cookies. It's to use actual multi-factor authentication and knowledge-based authorization. And Oracle can provide this via Oracle Adaptive Access Manager (OAAM).
Here is how OAAM could help in this scenario as quoted by one of our PM's in the Access Management Suite team:
OAAM uses many contextual information to determine the risk factor of any users performing any an action, whether it be viewing a resource or performing an action or or initiating a transaction. The contextual information covers things like IP address, geo-location, time of day, day of week, device fingerprinting (which can be done as a persistent object on the client machine), and even user behavior.
If I drill down on the use case a little bit, I believe you guys are looking for a way to raise risk factors when a user is coming in from a machine that the user has never used. The raised risk factor will require the user to answer an additional challenge question before the system can trust them enough to allow access to some resource.
So how does OAM and OAAM help accomplish the above? One example would be as follows:
The first time a user attempts access to a protected resource, OAM initiates an authentication scheme that really calls OAAM in the backend. OAAM then determines if the device has ever been used before based on device fingerprinting and if the machine is never used, then username, password, and a knowledge based question must all be provided before the user gets access. Subsequently, the user attempts access again with the persistent object (or device fingerprint) that OAAM accepts, then only username and password is necessary. This provides the knowledge based question as an added security measure if the user is coming from a machine that is never seen before. Of course, this solution assumes that the knowledge based questions and answers has already been set up for all users.
I also pitched a couple of other options - in particular if OAAM adoption would be slow to update for budget or time constraints:
1 - On sensitive pages - simply prompt for the password again. This would at least help with preventing someone who got access because the original person left the room.
2 - On sensitive pages - not only ask for a password but perhaps require a different pin code for that page.
3 - You could also use other authentication types -like digital certificates but that has its own set of headaches.
Also you can read more about OAAM.