In the coming years, many websites will contemplate adding strong authentication to accounts login. So far, early adopters for strong authentication have mostly been financial institutions. Since 2005, banks and brokerage firms have had had little choice than following the FFIEC guidance. This 2005 regulated mandated a move to stronger credentials than just name and passwords. Today, SAAS providers and large consumer Web sites are increasingly suffering brand exposure and public scrutiny following high visibility attacks (here and there). With increasing reliance on the cloud to host mission critical applications and sensitive data for enterprises and consumers, I would expect many large online services to begin offering stronger login options to their user base.
Interestingly, the FFIEC deployment of multi-factor solutions such as chase.com or bankofamerica.com give us some insight into the type of technology that are likely to be adopted by non financial service providers. Multi factor authentication essentially relies on a cookie as the second factor (the cookie is "what you have"). Coupled with a backend anomaly engine, the client side cookie is used as a "persistent" device identifier. Cookies as device IDs are alluring because they work across all browsers; they do not require any new client install on the user desktop; cookies are transparent to the end user, and most importantly, they do not cost anything. Since cookies could become prevalent as a "second factor" for web login, it is important to be aware of the security limitations and risk that they represent.
The first issue with cookies is their lack of persistence. Statistics show that users very often reset their cookie. This leads to the challenge of "cookie re-issuance" or cookie reset. This problem is roughly equivalent to password reset which, as many recognize, is the Achilles' heel of login. The alternative is not pretty. Either you make the reset process stringent and secure and it becomes a hassle to the end-user; or you make the process relatively easy, and it leads to very simple attacks. In short, the lack of persistence of cookie as device ID will trigger many cookie re-issuance events. Since high frequency life-cycle events cannot be made too complex without frustrating customers, the high frequency of cookie reset will inexorably lead to simple procedures. In turn, these simple procedures will inevitably open the door to a broad range of attacks.
The second class of problem with cookies is that they can easily be stolen using remote attacks such as cross-site scripting (XSS). XSS is a vulnerability that lets the attacker overcome the same origin policy enforced by all modern browsers. The policy circumvents scripts loaded from one domain to access content from another domain. XSS vulnerabilities effectively allow an attacker to execute scripts in the context of the vulnerable domain, hence overcoming the same origin safeguard in the browser. All the attacker needs to do is to exploit this vulnerability by crafting a request parameter value along the lines of ...document.cookie.... Since this gives the attacker unlimited access to any cookies of the website, DOM content, etc., this is considered one of the most serious vulnerabilities out there. The key about this type of cookie attack is that it can be launched remotely. In other words, an attacker can get to a user cookie without the user machine being compromised by malware. Add malware on the user machine, and cookies as a device ID become a recipe for disaster. In that case, cookies and machines fingerprints can be harvested and sent to the bad guys without the user ever noticing anything.
The increasing reliance on a silent device ID that does not impact the user experience is a logical approach to strengthening authentication on the Web. It is only the absence of alternative to cookies that is leading web engineers to leveraging them for authentication. Cookies were not invented for such purpose. As my sweet-tooth daughter would eloquently put it: the world need better cookies. Eventually, we do need stronger, more persistent devices ID that can be deployed across fixed and mobile devices, competing operating systems and browser platforms. These strong device IDs can be shared secrets, asymmetric key pairs or device certificates. The technology clearly exists but we lack a common deployment framework for device IDs (open client, common user experience, shared ID security stack, hardware protection too) .That is typically where the industry does it best work. Everyone needs it. Everyone will benefit from it. No one can do it alone.
The common need for open standard, open stack and open policies to deal with strong, persistent and privacy-conscious device IDs will inevitably lead to a joint effort. As cookies start crumbling across websites, security experts will get together and the urgency for collaboration will come to bear. In the meantime, when access security really matters, I will keep using my one time password token. If only, I could remember where I left it.