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
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
MITRE Releases 2019 List of Top 25 Software Weaknesses
Kelly Sheridan, Staff Editor, Dark Reading,  9/17/2019
Preventing PTSD and Burnout for Cybersecurity Professionals
Craig Hinkley, CEO, WhiteHat Security,  9/16/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-14821
PUBLISHED: 2019-09-19
An out-of-bounds access issue was found in the Linux kernel, all versions through 5.3, in the way Linux kernel's KVM hypervisor implements the Coalesced MMIO write operation. It operates on an MMIO ring buffer 'struct kvm_coalesced_mmio' object, wherein write indices 'ring->first' and 'ring->l...
CVE-2019-15032
PUBLISHED: 2019-09-19
Pydio 6.0.8 mishandles error reporting when a directory allows unauthenticated uploads, and the remote-upload option is used with the http://localhost:22 URL. The attacker can obtain sensitive information such as the name of the user who created that directory and other internal server information.
CVE-2019-15033
PUBLISHED: 2019-09-19
Pydio 6.0.8 allows Authenticated SSRF during a Remote Link Feature download. An attacker can specify an intranet address in the file parameter to index.php, when sending a file to a remote server, as demonstrated by the file=http%3A%2F%2F192.168.1.2 substring.
CVE-2019-16412
PUBLISHED: 2019-09-19
In goform/setSysTools on Tenda N301 wireless routers, attackers can trigger a device crash via a zero wanMTU value. (Prohibition of this zero value is only enforced within the GUI.)
CVE-2019-16510
PUBLISHED: 2019-09-19
libIEC61850 through 1.3.3 has a use-after-free in MmsServer_waitReady in mms/iso_mms/server/mms_server.c, as demonstrated by server_example_goose.