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
Threaded  |  Newest First  |  Oldest First
Cloud Security Threats for 2021
Or Azarzar, CTO & Co-Founder of Lightspin,  12/3/2020
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
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
Assessing Cybersecurity Risk in Todays Enterprises
Assessing Cybersecurity Risk in Todays Enterprises
COVID-19 has created a new IT paradigm in the enterprise and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27772
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in coders/bmp.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type `unsigned int`. This would most likely lead to an impact to application availability, but could po...
CVE-2020-27773
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/gem-private.h. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type `unsigned char` or division by zero. This would most likely lead to an impact to appli...
CVE-2020-28950
PUBLISHED: 2020-12-04
The installer of Kaspersky Anti-Ransomware Tool (KART) prior to KART 4.0 Patch C was vulnerable to a DLL hijacking attack that allowed an attacker to elevate privileges during installation process.
CVE-2020-27774
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/statistic.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of a too large shift for 64-bit type `ssize_t`. This would most likely lead to an impact to application availability, but co...
CVE-2020-27775
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/quantum.h. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type unsigned char. This would most likely lead to an impact to application availability, but c...