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.


05:56 PM
Taher Elgamal
Taher Elgamal

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
Newest First  |  Oldest First  |  Threaded View
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-17
The overlayfs implementation in the linux kernel did not properly validate with respect to user namespaces the setting of file capabilities on files in an underlying file system. Due to the combination of unprivileged user namespaces along with a patch carried in the Ubuntu kernel to allow unprivile...
PUBLISHED: 2021-04-17
Shiftfs, an out-of-tree stacking file system included in Ubuntu Linux kernels, did not properly handle faults occurring during copy_from_user() correctly. These could lead to either a double-free situation or memory not being freed at all. An attacker could use this to cause a denial of service (ker...
PUBLISHED: 2021-04-17
A command injection vulnerability has been reported to affect QTS and QuTS hero. If exploited, this vulnerability allows attackers to execute arbitrary commands in a compromised application. We have already fixed this vulnerability in the following versions: QTS Build 20210202 and later Q...
PUBLISHED: 2021-04-17
An SQL injection vulnerability has been reported to affect QNAP NAS running Multimedia Console or the Media Streaming add-on. If exploited, the vulnerability allows remote attackers to obtain application information. QNAP has already fixed this vulnerability in the following versions of Multimedia C...
PUBLISHED: 2021-04-16
jose-node-esm-runtime is an npm package which provides a number of cryptographic functions. In versions prior to 3.11.4 the AES_CBC_HMAC_SHA2 Algorithm (A128CBC-HS256, A192CBC-HS384, A256CBC-HS512) decryption would always execute both HMAC tag verification and CBC decryption, if either failed `JWEDe...