It's About The User

E-commerce was born 15 years ago when a bunch of us, thrilled by all of the possibilities and promise of the Web, said, "Let's adapt this new medium to do business." Even at that early moment, it was clear that user authentication would have to play an essential role if the adaptation was going to be successful.But the only actual example of successful strong authentication technologies that we had to go on at the time were the ones being used inside enterprise applications -- logins, single sign on, or hardware tokens. Inside enterprise applications, even before the Web started, we had been strongly authenticating employees and contractors and making sure that only the right people got access to the right stuff. It only made sense that the authentication products and technologies that had enjoyed so much success in the enterprise world could be adapted to the e-commerce world. After all, both of these sets of products were labeled "authentication," so they must be the same thing, right?

Not quite.

Within enterprise boundaries, the enterprise has a pre-existing relationship with the employee. When the employee logs into the enterprise's server, application, or network, the enterprise can require the employee to log in using a certain method, using a certain authentication system (e.g., the popular SecureID products, etc.) that the employee will quickly get used to and freely adopt. Here, the user -- an employee obligated to follow a set of rules -- was thought of first, and the protocol fit it nicely.

But this concept simply doesn't work for e-commerce. Merchants don't have the same relationship with customers as companies do with workers. They can't spell out requirements and reasonably expect a customer to feel obligated to fulfill those requirements. Here, the user -- a consumer who is not obligated to follow a set of rules -- was not thought of first, so demanding anything out of them was simply out of the question. To add to that complexity, each employee has a relationship with one (or very few) employers, but a consumer has relationships with many e-commerce providers, each choosing their favorite style of authentication without regard to "ease of use."

Consider banks, for example. In the beginning, almost all of the banks I talked to hesitated to ask their customers to do anything more than enter login/password credentials. Yet, despite the reliance on login/password credentials being terribly risky, the practice persisted, and it wasn't until some wise people in the banking industry told the government that there are better authentication technologies than passwords -- that the login/password convention was largely responsible for a rash of security breaches -- that two-factor authentication became a banking-industry standard.

Even then, when every bank implemented two-factor authentication, they each did it their own way, and with wildly varying results: some were technologically great, easy for the users to grasp, and easy to deploy; some were not so great, leaving the users confused; and still others were easy for the users to understand but hard to deploy or expensive to operate.

But this initial hesitance, this unwillingness to take the long route (which, as I mentioned, eventually gets taken anyway, after government regulators step in), characterized more than just the banks' unwillingness to make demands of their customers.

It characterized the development of e-commerce itself.

Instead of looking at e-commerce as a new medium and optimizing it by filling the gaps in the Web that needed filling, we took short cuts, ignored certain pieces, and got it to work. It grew very fast and became a wonderful success story, but at a price: by ignoring certain pieces, we invited countless parties to improvise their own methods for authentication. And improvisation -- force-fitting products to satisfy security demands, rather than looking at the real requirements of the security demands and developing the appropriate products -- is the wrong way to go.

It's particularly the wrong way to go when B2B applications inherit improvised features that "worked" for enterprise applications and e-commerce. Fortunately, today, in 2010, the long route is being taken, and B2B application developers know they have a different set of requirements to satisfy. They are asking themselves, "How do I authenticate businesses to one another and ensure that the interaction is between the right two businesses?" At the same time, they're challenging themselves to use two-factor authentication, the very thing that was initially overlooked in e-commerce. They know that we will not be able to deploy tokens to business partners. They know that we will not be able to depend on simple password schemes to allow business partners to access and operate important assets.

And this is a very good thing. With the B2B world taking the long route, they will know what the real requirements are, how to substitute the Internet for old networks, how to preserve existing security properties, and how to manage everything correctly. They will not leave users confused, as banks and other agents of e-commerce did. They will instead bolster adoption of the technology because they thought of the user first.

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.