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

11/9/2010
09:43 AM
Taher Elgamal
Taher Elgamal
Commentary
50%
50%

A True Second Factor

I'm sure some of you remember a time when you actually used to telephone the bank to do a transaction. Do you remember all the questions they would ask to verify that you were, in fact, the account owner?

I'm sure some of you remember a time when you actually used to telephone the bank to do a transaction. Do you remember all the questions they would ask to verify that you were, in fact, the account owner?"What's your zip code?"

"What's the last four digits of your social security number?"

"What's your mother's maiden name?"

For a transaction over the telephone, this was fine.

But at some point in the early days of e-commerce, somebody decided that, since login/password credentials alone weren't enough for telephone transactions, this approach should be applied to e-commerce transactions, too.

Fast forward to today and you see all those same questions popping up when you're trying to log into a brand new account, log into an old account on a new laptop, transfer money to a new place, etc.

But there are serious issues with this sort of knowledge-based authentication, not the least of which is that we're sharing private information with countless website owners whose moral integrity is impossible to know.

This private information, it turns out, comes up into side channels apart from the website, too, which means it's just as possible to phish private information as it is to phish login/password credentials. It also means that, from my point of view, knowledge-based authentication gives you an iota of increased security at best.

I say "an iota of" rather than "no" because a hacker would have to phish a number of different knowledge-based elements to effectively pull off an act of identity theft. Nevertheless, knowledge-based authentication is -- let's be frank -- far more annoying than it's worth thanks to the ubiquity of phishing. Any form -- and subsequently anything that goes into a form -- can be mimicked by bad guys. If you inadvertently land on their website and fill out their forms without checking the URL bar and recognizing that this site isn't even remotely the place you want to be, your private information will be phished.

Again, it underscores the shortsightedness of applying old security methods that worked well in the past to new scenarios that today demand a greater level of sophistication. With the telephone, there were no issues with forms being mimicked by bad guys. In fact, there were no forms at all. You were actually talking to your bank, they were actually talking to you, and it was far more difficult for a third party in the past to get in the middle of that transaction -- to glean information from a two-party telephone call -- than it is for a third party today to get in the middle of an electronic transaction via a well-placed form on the Internet.

This brings us once again to the importance of two-factor authentication, particularly the use of one-time password tokens.

If you've ever received a code that a website texted to your cell phone and asked you to re-enter on the website, you've had experience with these tokens.

Now, you may ask yourself, "Is this a good security strategy? Relying on the user to have a cell phone?"

And you may be surprised when I say that yes, in fact, I think it is a good strategy.

Think about it. Anyone who is going to log into a website probably has a cell phone. (According to the International Telecommunication Union, a U.N. agency that regulates information and communication technology issues, "By the end of 2010, there will be an estimated 5.3 billion mobile cellular subscriptions worldwide, including 940 million subscriptions to 3G services.")

To breach that security measure, a hacker would have to have a user's laptop and cell phone in their possession -- an unlikely prospect, to say the least.

Now that's a true second factor, one wholly independent of the first. Its user has nothing to fear from a laptop going missing or getting stolen. Its user has nothing to fear from a bad guy learning the password to the user's account.

I believe two-factor -- perhaps even multiple-factor -- authentications like this will be the way of the future for many e-commerce sites. But because there is really no user authentication scheme of any type underneath them, every site will have to be diligent about which authentication methods they choose. And while we still haven't solved the problem of confusing the user -- haven't figured out a way of putting the user first 100 percent of the time -- we'll at least be doing right by the user, vigorously protecting their information to the very end, with an authentication protocol that's extraordinarily tough to beat.

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
When It Comes To Security Tools, More Isn't More
Lamont Orange, Chief Information Security Officer at Netskope,  1/11/2021
US Capitol Attack a Wake-up Call for the Integration of Physical & IT Security
Seth Rosenblatt, Contributing Writer,  1/11/2021
IoT Vendor Ubiquiti Suffers Data Breach
Dark Reading Staff 1/11/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's 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-25533
PUBLISHED: 2021-01-15
An issue was discovered in Malwarebytes before 4.0 on macOS. A malicious application was able to perform a privileged action within the Malwarebytes launch daemon. The privileged service improperly validated XPC connections by relying on the PID instead of the audit token. An attacker can construct ...
CVE-2021-3162
PUBLISHED: 2021-01-15
Docker Desktop Community before 2.5.0.0 on macOS mishandles certificate checking, leading to local privilege escalation.
CVE-2021-21242
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, there is a critical vulnerability which can lead to pre-auth remote code execution. AttachmentUploadServlet deserializes untrusted data from the `Attachment-Support` header. This Servlet does not enforce any authentication or a...
CVE-2021-21245
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, AttachmentUploadServlet also saves user controlled data (`request.getInputStream()`) to a user specified location (`request.getHeader("File-Name")`). This issue may lead to arbitrary file upload which can be used to u...
CVE-2021-21246
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, the REST UserResource endpoint performs a security check to make sure that only administrators can list user details. However for the `/users/` endpoint there are no security checks enforced so it is possible to retrieve ar...