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
The Cold Truth about Cyber Insurance
Chris Kennedy, CISO & VP Customer Success, AttackIQ,  11/7/2019
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
6 Small-Business Password Managers
Curtis Franklin Jr., Senior Editor at Dark Reading,  11/8/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
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16863
PUBLISHED: 2019-11-14
STMicroelectronics ST33TPHF2ESPI TPM devices before 2019-09-12 allow attackers to extract the ECDSA private key via a side-channel timing attack because ECDSA scalar multiplication is mishandled, aka TPM-FAIL.
CVE-2019-18949
PUBLISHED: 2019-11-14
SnowHaze before 2.6.6 is sometimes too late to honor a per-site JavaScript blocking setting, which leads to unintended JavaScript execution via a chain of webpage redirections targeted to the user's browser configuration.
CVE-2011-1930
PUBLISHED: 2019-11-14
In klibc 1.5.20 and 1.5.21, the DHCP options written by ipconfig to /tmp/net-$DEVICE.conf are not properly escaped. This may allow a remote attacker to send a specially crafted DHCP reply which could execute arbitrary code with the privileges of any process which sources DHCP options.
CVE-2011-1145
PUBLISHED: 2019-11-14
The SQLDriverConnect() function in unixODBC before 2.2.14p2 have a possible buffer overflow condition when specifying a large value for SAVEFILE parameter in the connection string.
CVE-2011-1488
PUBLISHED: 2019-11-14
A memory leak in rsyslog before 5.7.6 was found in the way deamon processed log messages are logged when $RepeatedMsgReduction was enabled. A local attacker could use this flaw to cause a denial of the rsyslogd daemon service by crashing the service via a sequence of repeated log messages sent withi...