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.


04:42 PM
Taher Elgamal
Taher Elgamal

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
Newest First  |  Oldest First  |  Threaded View
AI Is Everywhere, but Don't Ignore the Basics
Howie Xu, Vice President of AI and Machine Learning at Zscaler,  9/10/2019
Fed Kaspersky Ban Made Permanent by New Rules
Dark Reading Staff 9/11/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-09-14
In Pimcore before 5.7.1, an attacker with limited privileges can trigger execution of a .phar file via a phar:// URL in a filename parameter, because PHAR uploads are not blocked and are reachable within the phar://../../../../../../../../var/www/html/web/var/assets/ directory, a different vulnerabi...
PUBLISHED: 2019-09-14
In Pimcore before 5.7.1, an attacker with limited privileges can bypass file-extension restrictions via a 256-character filename, as demonstrated by the failure of automatic renaming of .php to .php.txt for long filenames, a different vulnerability than CVE-2019-10867 and CVE-2019-16317.
PUBLISHED: 2019-09-14
A Reflected Cross-Site Scripting (XSS) vulnerability in the webEx module in webExMeetingLogin.jsp and deleteWebExMeetingCheck.jsp in Fuji Xerox DocuShare through 7.0.0.C1.609 allows remote attackers to inject arbitrary web script or HTML via the handle parameter (webExMeetingLogin.jsp) and meetingKe...
PUBLISHED: 2019-09-14
SciLexer.dll in Scintilla in Notepad++ (x64) before 7.7 allows remote code execution or denial of service via Unicode characters in a crafted .ml file.
PUBLISHED: 2019-09-14
FlameCMS 3.3.5 has SQL injection in account/login.php via accountName.