Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

10/19/2010
04:42 PM
Taher Elgamal
Taher Elgamal
Commentary
50%
50%

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.

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
I 'Hacked' My Accounts Using My Mobile Number: Here's What I Learned
Nicole Sette, Director in the Cyber Risk practice of Kroll, a division of Duff & Phelps,  11/19/2019
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-2079
PUBLISHED: 2019-11-22
A cross-site request forgery (CSRF) vulnerability in the Activity module 6.x-1.x for Drupal.
CVE-2019-11325
PUBLISHED: 2019-11-21
An issue was discovered in Symfony before 4.2.12 and 4.3.x before 4.3.8. The VarExport component incorrectly escapes strings, allowing some specially crafted ones to escalate to execution of arbitrary PHP code. This is related to symfony/var-exporter.
CVE-2019-18887
PUBLISHED: 2019-11-21
An issue was discovered in Symfony 2.8.0 through 2.8.50, 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. The UriSigner was subject to timing attacks. This is related to symfony/http-kernel.
CVE-2019-18888
PUBLISHED: 2019-11-21
An issue was discovered in Symfony 2.8.0 through 2.8.50, 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. If an application passes unvalidated user input as the file for which MIME type validation should occur, then arbitrary arguments are passed to the underlying file command. T...
CVE-2019-18889
PUBLISHED: 2019-11-21
An issue was discovered in Symfony 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. Serializing certain cache adapter interfaces could result in remote code injection. This is related to symfony/cache.