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

9/29/2010
05:56 PM
Taher Elgamal
Taher Elgamal
Commentary
50%
50%

User Authentication In E-Commerce

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.

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.

Comment  | 
Print  | 
More Insights
Comments
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
Video
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
CVE-2019-14540
PUBLISHED: 2019-09-15
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to com.zaxxer.hikari.HikariConfig.
CVE-2019-16332
PUBLISHED: 2019-09-15
In the api-bearer-auth plugin before 20190907 for WordPress, the server parameter is not correctly filtered in the swagger-config.yaml.php file, and it is possible to inject JavaScript code, aka XSS.
CVE-2019-16333
PUBLISHED: 2019-09-15
GetSimple CMS v3.3.15 has Persistent Cross-Site Scripting (XSS) in admin/theme-edit.php.
CVE-2019-16334
PUBLISHED: 2019-09-15
In Bludit v3.9.2, there is a persistent XSS vulnerability in the Categories -> Add New Category -> Name field. NOTE: this may overlap CVE-2017-16636.
CVE-2019-16335
PUBLISHED: 2019-09-15
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to com.zaxxer.hikari.HikariDataSource. This is a different vulnerability than CVE-2019-14540.