When we designed SSL to enable e-commerce on the Web, we had to solve two issues. One was the Web's openness -- the fact that anybody can read anything -- and the other was how parties might authenticate with one another.Today, 15 years later, SSL secures more than $300 billion in e-commerce annually, not counting B2B traffic, and yet no applications use the PKI support that we put in SSL to authenticate clients into SSL. Not surprisingly, the amount of fraud in e-commerce is far higher than it is in physical-world transactions. This is perhaps due to the lack of user authentication in online payments, but is this lack the result of a reaction to the cost associated with user authentication? Is there a concern that implementation slows down consumer adoption of e-commerce? Whatever the case might be, authentication's progress during the past 15 years has, frankly, been all over the place.

From the beginning, larger merchants, like Amazon and eBay, created accounts to solve the authentication problem (while maintaining a close relationship with their customers), and because of this we all have dozens of accounts throughout the Web, most of which use the standard username/password convention. But since passwords can be gleaned from phishing and dictionary attacks, other factors are often verified, like whether the IP address the user is logging in from is the same one the merchant has associated with the user's account.

While e-commerce merchants will always maintain accounts for their customers, enforcing different levels of authentication using that mechanism creates several security issues, the simplest of which arises from the fact that users normally use the same password for multiple sites, and e-commerce merchants could, therefore (and rather unnecessarily), have a great deal of access to their customers' private information.

For some time, online banking applications also used nothing more than the standard username/password convention. But when the number of phishing attacks grew exponentially, the financial industry responded by insisting on two-factor authentication, and each bank decided on its own factors because there was not (and is still not) an overall authentication technology for e-commerce or even banking on the Web.

To illustrate, let's say you log into a bank's website, and the bank uses two-factor authentication. It recognizes your laptop as the same laptop you used to log into its site before, and everything is fine. But let's say you log in from a new laptop, or perhaps a workstation at your office. You'll then be subject to specific questions -- a standard knowledge-based tactic. The idea can be summed up like this: "If I don't know that this laptop belongs to John Smith, then I'm going to ask its current user some questions, and if he answers all of them correctly, then I'll feel comfortable that this is, in fact, John Smith."

The session that results from this actually still stands to be hijacked by malware, however, so a second layer of transaction-level authentication is necessary. When you wire money out of an account or transfer funds between banks, a secondary authentication box appears and asks you to type a CAPTCHA or put in your password again. The reason for this is that it prevents malware from actually sending transactions on your behalf during an authenticated session.

The result today is there is a number of different authentication mechanisms that users on the Web have to go through to authenticate themselves to different sites. There have been multiple efforts to attempt to consolidate, or at least somewhat unify, authentication on the e-commerce Web -- all of the identity federation ideas and Liberty Alliance efforts, for instance -- and they're really good technically.

The problem is that business models stand in the way.

Different businesses don't necessarily want other businesses to know who their customers are. Trying to relay an identity from one bank to the other or from one e-commerce site to another could tell a second site that a person is a customer of the first site -- information that nobody is willing to share. So there are business issues in the way of growing the identity federation space over the Web the way we had wanted to when the Liberty Alliance efforts started many years ago, despite all the Open ID ideas, Microsoft concepts, and efforts to consolidate authentication in the e-commerce world.

After all of this, SSL is still running 100 percent of e-commerce in the world, which is kind of fascinating. And yet there's no SSL authentication or any unified e-commerce user-authentication anywhere. If user authentication becomes part of the infrastructure, rather than a function of the specific site, then the growth and trust in e-commerce will be even larger than we are experiencing today. (And since e-commerce has been in existence for a while now, there may also be ways to authenticate users just through the Web, without involving the user too many times.)

Somehow, the difficulties we experienced in the early days of PKI made it seem like there was a fundamental issue with issuing digital certificates to users. If we re-examine this issue today, then perhaps the issue can be mitigated handily: Give the user a strong, easy-to-use authentication technology, one we can all benefit from.

In my next post, I'll continue my reflections on SSL and explore its relationship to enterprise apps, B2B apps, and B2B authentication.

Recognized in the industry as the "inventor of SSL," Dr. Taher Elgamal led the SSL efforts at Netscape. He also wrote the SSL patent and promoted SSL as the Internet security standard within standard committees and the industry. Dr. Elgamal invented several industry and government standards in data security and digital signatures area, including the DSS government standard for digital signatures. In addition to serving on numerous corporate advisory boards, Dr. Elgamal is the Chief Security Officer at Axway, a global provider of multi-enterprise solutions and infrastructure. He holds a Ph.D. and M.S. in Computer Science from Stanford University.