Perimeter
11/26/2011
05:09 PM
Taher Elgamal
Taher Elgamal
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Will Software Authentication Survive?

Protecting secret keys or seeds in software without the risk of being stolen is crucial

I have been thinking about the possibility of software authentication tokens for a while. There are a few movements in the industry to make hardware authentication easier to use and deploy, but there certainly are many cases where software tokens are preferred or required.

The first question is whether it is possible to have software tokens that are cryptographically strong. That means having a way to protect secret keys or seeds in software without the risk of being stolen. There have been attempts for this offering in the past, for sure -- the most used today are Arcot IDs offered by CA. These methods have been in commercial use for many years and have proved to be strong against any attacks.

The second issue is whether there are reasons for software authentication -- and the answer here is obvious given the availability of hardware authentication is still quite limited and will take a long time for the market to be there. Many of the financial (and other) sites today use mobile phones as a second factor for authentication. The use of strong cryptography there with a software one-time password will provide a very strong second factor that does not need secure hardware.

My prediction: Software second-factor authentication technologies will be here for a long time -- perhaps for the very long-term.

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. 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
Scott G.
50%
50%
Scott G.,
User Rank: Apprentice
1/21/2012 | 8:39:26 PM
re: Will Software Authentication Survive?
First, my compliments - it's great to see a lively and intelligent discussion (debate?) occurring with insults and name-calling as there have been in so many other responses.-á I appreciate the others on this page taking the time to reply so thoughtfully.

In regards to the comments by RichieB, while I concur that MITM attacks can be detrimental to some forms of 2FA we believe that we have found a way to minimize or effectively block them.-á The mobile-originated (MO) SMS solution-á (patent-pending, I should note) uses the UDID of the mobile device, which is deeply embedded into the core OS of the device and is a significant hurdle to overcome.-á Normal malware or MITM attacks will not succeed with this methodology.-á

To explain: In order to spoof the UDID an intruder would have to figure out a way to replace the entire portion of the operating system that runs the over the air (OTA) protocol.-á This OTA protocol, furthermore, isn't only one packet.-á There is an almost overwhelming list of additional packets that must be violated and duplicated such as the phone registration protocols, cell site transfer messages, frequency selection messages and power level-setting messages.-á On top of all this the intruder would have produce proper responses to any user level messages that might have to be similarly spoofed to complete an attack.

Before a phone can send anything, it needs to find a cell tower, negotiate with it to get assigned a channel, etc. The UDID is used on those messages also and thus spoofing attempts without the hardware-specific UDID will be blocked by the carrier at multiple points along the route to completion.-á In other words, with each barrier the chances of a MITM attack - or any other kind that attempts to spoof or steal the UDID or code that must be sent, becomes increasingly so infinitesimal as to almost completely disappear.-á

You would, in fact, have to have physical possession of the wireless device in order to even learn the UDID, much less to spoof it.-á And, of course, the necessity of doing this all in a 60-second window while the code is valid makes it, shall we say, remote.-á In fact, to fake a UDID you would have to be a cell phone engineer as well as a hacker.-á

While we are certainly not brazen or foolish enough to claim that the MO-SMS-2FA (how's that for a convoluted acronym?) is impervious to intrusion we do believe that it is a more secure, more convenient and less expensive solution than anything else currently available.-á
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3409
Published: 2014-10-25
The Ethernet Connectivity Fault Management (CFM) handling feature in Cisco IOS 12.2(33)SRE9a and earlier and IOS XE 3.13S and earlier allows remote attackers to cause a denial of service (device reload) via malformed CFM packets, aka Bug ID CSCuq93406.

CVE-2014-4620
Published: 2014-10-25
The EMC NetWorker Module for MEDITECH (aka NMMEDI) 3.0 build 87 through 90, when EMC RecoverPoint and Plink are used, stores cleartext RecoverPoint Appliance credentials in nsrmedisv.raw log files, which allows local users to obtain sensitive information by reading these files.

CVE-2014-4623
Published: 2014-10-25
EMC Avamar 6.0.x, 6.1.x, and 7.0.x in Avamar Data Store (ADS) GEN4(S) and Avamar Virtual Edition (AVE), when Password Hardening before 2.0.0.4 is enabled, uses UNIX DES crypt for password hashing, which makes it easier for context-dependent attackers to obtain cleartext passwords via a brute-force a...

CVE-2014-4624
Published: 2014-10-25
EMC Avamar Data Store (ADS) and Avamar Virtual Edition (AVE) 6.x and 7.0.x through 7.0.2-43 do not require authentication for Java API calls, which allows remote attackers to discover grid MCUser and GSAN passwords via a crafted call.

CVE-2014-6151
Published: 2014-10-25
CRLF injection vulnerability in IBM Tivoli Integrated Portal (TIP) 2.2.x allows remote authenticated users to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.