The capabilities of today’s browsers are not sufficient for meeting the security needs of web applications requiring authentication and payments. One of the two primary deficiencies is that content from one site cannot be adequately sandbox when executed on a relying web site. Yet embedding such third party micro-apps has become commonplace. The second deficiency is the reliance on passwords, as is so eloquently described by this post from Eevee.
Take making a PayPal transaction at a merchant web site as an example of the first deficiency. To make this work the merchant web site must redirect the user to PayPal’s web site where he or she then authenticates and authorizes the payment. The user is taken out of context, away from the merchant’s web site, with the possibility of being subject to phishing. This is done because any PayPal code running within the context of the merchant’s site would not be secure: PayPal and the merchant cannot isolate each other’s code.
There are other examples where this sandbox deficiency is apparent: Open ID, Verified by VISA and Secure Vault Payments (SVP ACH payments) are just a few. VBV and SVP are particularly jaring because the user is taken out of the context of their nice, modern web app, redirected to the archaic web site of some bank, then (hopefully) redirected back to complete the transaction.
Amongst social media Facebook Connect is the most common example; though sandboxing appears to be counter to Facebook’s data collection interests. Disqus too allows micro-app authentication. One might argue that passwords harvested from sites like Disqus have little value, but think again, they do.
Making this work in the browser
- key strokes intended for the micro-app are not intercepted by the host web page
- the micro-app’s user interface wasn’t being visually compromised by the host (for example by overlaying misleading UI)
- the micro-app is not from a phisher
The only secure way to make this work is to put the 3rd party content in it’s own browser window. This way the code and UI are isolated from the host application and the browser’s address bar can show the SSL security status of the micro-app. A problem is that API communications between the host page and micro-app is then limited to URLs and the user experience suffers.
How this could work
When I ran the security group for Adobe Acrobat we had a number of customers tell us that they would have liked to have taken the credential solutions that we were using in Acrobat and made them available to improve authentication within the browser. A pharmaceutical company could then have an employee login to a web site using the same managed credentials that they used to sign PDF files.
This sounds very much like an OS-level function that all applications on the platform should have access to, and yet the OS and browser vendors continued to build isolated security stacks and did not manage to improve browser user authentication. At Adobe we were pondering ways of filling this void and enabling Acrobat credentials to be used in the browser (via a plugin) when Adobe and Macromedia merged.
Macromedia Flash presented a new opportunity for my group. If we could expose strong credentials via both the Flash runtime and Acrobat Reader we would have near ubiquitous reach. Flash had a number of very special characteristics:
- Code from one site could be bundled and run in a secure sandbox on another web site
- Flash could be used to present a slick, top-of-screen user interface that could not be spoofed
- Flash could be enhanced to provide access to the operating system for secure key storage
Add in the promise of Adobe AIR and we had the opportunity to deliver credentials that could be used across a large range of applications. Even native apps could be extended to load and run Flash apps.
Let’s look at why this would have been valuable. Imagine if a merchant could expose a PayPal widget (rectangle of UI) right within the merchant’s own web site without the need for a redirect. The widget would have access to the user’s PayPal credentials that had previously been activated on the user’s machine, and so PayPal could use strong, non-spoofable authentication for the transaction.
The widget would be top of screen and use security indicators to provide a safe user interface that the user would trust to complete the transaction, much like a POS device at a grocery store is trusted. Security indicators are fragments of UI that the user has previously configured to ensure that the widget was not being spoofed. SiteKey is an example of a security indicator mechanism, though not a very good one. Widget participants would also be white listed via a separate mechanism then is used by today’s browsers thus eliminating phishing and the need for users to distinguish SSL or EVSSL sites.
The in-page experience, sandboxing of code and user interface, and the ability to prevent spoofing, were the most important aspects of this solution. I created a project called Flashcard within Adobe’s Advanced Technology Labs that proved the concept’s preliminary technical feasibility. All that was needed was an additional 50K of code in Flash to make it happen. We would have allowed companies to build their own widgets, but to improve adoption we were proposing a standardized Flashcard wallet that all could use.
Microsoft had a similar technology called Cardspace, but the user experience was seriously lacking and it seemed obvious that the solution was overweight and had little chance of success. Open ID was started at about the same time as we were looking at Flashcard, but again the complexity of redirects and poor user experience predictably killed it. Adobe’s CTO Kevin Lynch had different priorities at the time and chose not to pursue Flashcard.
And then there’s the problem of passwords
As Eevee’s post on passwords points out, there do exist good models for authentication. Techies use SSH and private key cryptography every day to login to remote sites and do serious work. The use of private keys actually makes life easier because the user doesn’t need to remember and maintain passwords, and they can use the same private key to authenticate to any number of sites. What is needed to make this work for browsers is a ubiquitous and functionally complete secured lockbox such as Mac OS X’s keychain, or Microsoft Windows’s DPAPI.
What I mean by ubiquitous and functionally complete is that a web site author can actually count on the technology existing across browsers and for it to deliver the type of key lifecycle management features that a web site needs. This too was a part of Flashcard. Flashcard was to provide a an authenticated key store, available across browsers and platforms, that could store private keys and other types of tokens and assertions.
Not much to look forward to
I am not suggesting that FlashCard itself was the answer to all of these problems. FlashCard was a concept that had not yet been fully explored. I am suggesting that there is in fact a better way to do authentication, and that there is value in providing a code and UI isolated mechanism that provides a better bridge between micro-apps and host pages.
The problems of relying on passwords, inadequate sandboxing and use of redirects continues to exist in the browser and I see no solutions on the horizon. The best hope is if one of the browser manufacturers works out a binary solution and steps up to propose a standard. Even better is if an OS vendor could be brought on board to make the solution available to mobile and desktop apps as well as web apps. In today’s market the only two companies who can achieve this success are Google and Apple, with an outside chance of Mozilla acting an instigator. Unfortunately, as Eevee writes in regard to passwords, “Nobody with the resources to pull off something usable is inclined to do so.”