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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/23/2020
Modern Day Insider Threat: Network Bugs That Are Stealing Your Data
David Pearson, Principal Threat Researcher,  10/21/2020
Are You One COVID-19 Test Away From a Cybersecurity Disaster?
Alan Brill, Senior Managing Director, Cyber Risk Practice, Kroll,  10/21/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-10-27
checkpath in OpenRC through 0.42.1 might allow local users to take ownership of arbitrary files because a non-terminal path component can be a symlink.
PUBLISHED: 2020-10-26
libtac in pam_tacplus through 1.5.1 lacks a check for a failure of RAND_bytes()/RAND_pseudo_bytes(). This could lead to use of a non-random/predictable session_id.
PUBLISHED: 2020-10-26
An out-of-bounds read in the JavaScript Interpreter in Facebook Hermes prior to commit 8cb935cd3b2321c46aa6b7ed8454d95c75a7fca0 allows attackers to cause a denial of service attack or possible further memory corruption via crafted JavaScript. Note that this is only exploitable if the application usi...
PUBLISHED: 2020-10-26
Ruckus through is affected by remote command injection. An authenticated user can submit a query to the API (/service/v1/createUser endpoint), injecting arbitrary commands that will be executed as root user via web.py.
PUBLISHED: 2020-10-26
Ruckus vRioT through has an API backdoor that is hardcoded into validate_token.py. An unauthenticated attacker can interact with the service API by using a backdoor value as the Authorization header.