Operations // Identity & Access Management
2/4/2014
05:15 PM
Garret Grajek
Garret Grajek
Commentary
Connect Directly
LinkedIn
Google+
RSS
E-Mail
50%
50%

The Problem With Two-Factor Authentication

The failure of corporate security strategies to protect personal identity information from hackers resides more with system architecture than with authentication technology. Here's why.

For too long, enterprises have been looking for the perfect two-factor authentication. First, it was X.509, then hard tokens, then SMS, and now Push and biometrics. And still, hackers keep winning. Just look at what happened with Target, Neiman Marcus, Living Social, Snapchat, and others.

The problem isn't the two-factor authentication technology. To be more specific, it's not just the two-factor authentication. It's the full integration, which includes the storage, accessing, validation, and assertion of identity throughout the authentication process.

But don't take my word for it. The forensics on most recent hacks reveal that hackers did not break the authentication mechanism itself. Rather, they broke the integration -- the identity passing and storage. That tells me websites (cloud or enterprise-based) that demand bulletproof security need to understand how authentication (single- or two-factor) is provisioned, conducted, validated from enterprise information, and asserted to the final resource -- and ultimately how the trust is reused at other resources.

How the authentication is provisioned
By this, I mean how the ID itself is granted to the user and how the credentials are provided to the users. The authentication process (single- or two-factor) should be quantified and scrutinized for weaknesses. One of the best ways to increase security in this procedure is to remove all human interaction (think: how to remove help desk interaction). You can validate users based on enterprise data or third-party social IDs and other data sources. You can then grant users reusable two-factor authentication credentials such as an X.509 certificate, an identity card, a mobile OATH token, or just the device itself.

Ideally, the registration process should be browser-based, which enables communication to match the client's native language automatically. Too often, however, each of these functionalities is siloed (e.g., coded after the two-factor product is purchased), and this is where the hacks occur. The hackers are breaching the architecture, not the authentication mechanism.

How and where the authentication takes place
Too often the validation algorithm is hosted or housed on servers or services that are beyond an enterprise's security control. These servers and services need to be scrutinized, because it is usually much easier for a hacker to breach the actual identity collection form (web or other form) than the actual authentication mechanism itself via cross-site scripting, SQL injection, or another attack vector against the form collector. Of course, this raises a raft of additional questions. Who wrote these collection forms? Are they housed on secure, enterprise servers? Have the forms been pen tested? Were they written by an outsourced contract service or hosted on insecure servers?

How the authentication is validated from enterprise PII
Most of the recent attacks have targeted enterprise-held personally identifiable information (PII), in which two-factor authentication methods prompted the company to sync up or migrate PII to other holders. As the Snapchat breach of 4.6 million users' phone numbers demonstrated, organizations need to secure their PII with the same security they use to keep passwords and other authentication information safe. Authentication information is, by its nature, PII, and allowing other services, especially authentication services, to use this data is simply asking for trouble.

How the authenticated identity is validated
Many authentication methods were created before resources like cloud and native mobile applications existed. As a result, common authentication mechanisms, such as tokens, were designed to use dated authentication protocols, like RADIUS, for resource-to-data-store validation. This type of authentication usually assumes that there is a proxy between the resource and the user, which is not always possible in the cloud and with mobile apps. In response, enterprises have implemented hackable integration methodologies that introduce vulnerabilities in the credential collection and identity-passing processes for these new resources.

Cloud resources should be secured with cryptographically signed assertions, like SAML or WS-Fed; similar mechanisms, including cryptographically validated web services, can be used for identity passing to native mobile apps. But these mechanisms are only as good as the services that encompass the identity passing. If the authentication system is separate from the identity-passing system, your enterprise needs to ensure that this transfer process is secure each and every time.

Don't ignore user fatigue
Ideally, all systems that users access (including network, cloud, enterprise, and mobile), should be set up to conduct some sort of identity validation. But if the enterprise forces a high-friction authentication such as SMS, token, or telephony, where the user has to re-enter credentials every session, it's pretty much guaranteed that the user will find a way to circumvent the best mechanisms and/or burden the help desk with repeated account lockouts or two-factor registration requests.

To alleviate this burden, SSO is the best solution. Look at consolidating enterprise resources into mechanisms that lend themselves to portal access where a single authentication (preferably, a strong one) allows access to multiple resources. Role-based is ideal, depending on what resources a particular user should see.

Organizations that demand bulletproof security must understand that true security is not in the authentication process alone. It's only when the entire system architecture -- from provisioning and validation through asserting identity -- is addressed from a security perspective that personal information will be truly safe from attack.

Garret Grajek is a CISSP-certified security engineer with more than 20 years of experience in the information security and authentication space. As Chief Technical Officer and Chief Operating Officer for SecureAuth Corp., Garret is responsible for the company's identity ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 4   >   >>
Auth_Pro
100%
0%
Auth_Pro,
User Rank: Apprentice
2/7/2014 | 3:07:47 PM
Preformed head to head with toopher,secureauth, okta, duo & securid
After a month long review of Toopher, Duo Security, Okta, SecureAuth and SecurID I can say that gartner was right about secureauth having the best customer service in the authentication space.  Toopher support was non existent, okta sales were pushy as heck, securid was a workable dinosaur which left duo and secureauth.  What secureauth put together was something that deployed quickly and worked for our use cases, duo deployed quickly too but only covered half of our use cases.
GGRAJEK
100%
0%
GGRAJEK,
User Rank: Apprentice
2/7/2014 | 3:07:20 PM
Re: Duo Security
Duo has very nice PUSH authentication - but as I stated - relying on a single form factor for authentication is setting the enterprise up for failure.    THe key is too abstract the authenticaiton and then be able to select the form factor most appropriate, PUSH Notification being one of the choices.   (THe others being  SMS, Telephony, X.509, OATH MObile tokens, Hard Tokens,  Gov't Issue  Credentials, Smart Cards, Social IDs, etc.)

And most importantly - construct a solution - that allows rapid (and secure) delivery/deployment of these authentication methodologies.   E.G. - as stated - this is where the hacks are occruing. 

 
CalistaHerdhart
100%
0%
CalistaHerdhart,
User Rank: Apprentice
2/7/2014 | 2:52:24 PM
Re: Two factor is useful after the data breach
Yea, we tried SecureAuth and it was great, transparent 2factor that worked with all of our cloud and internal apps, sso and password reset included.  Covered everything at a price point we could live with.  bye bye rsa securid tokens
moarsauce123
100%
0%
moarsauce123,
User Rank: Apprentice
2/7/2014 | 2:49:27 PM
Re: Two factor is useful after the data breach
We tried Toopher here and it was a horrible waste of time...  Ended up looking elsewhere at the time, didn't know about Garret's concept which looks great.
anon2284099262
100%
0%
anon2284099262,
User Rank: Apprentice
2/7/2014 | 1:18:09 PM
Re: Two factor is useful after the data breach
RE Toopher, What would happen if someone stole your phone and knew where you did business. I would think that is sort of a single point of failure. 
Beck
0%
100%
Beck,
User Rank: Apprentice
2/7/2014 | 12:10:23 PM
Re: Two factor is useful after the data breach
Woah, thanks for the quick response! I didn't realize how many users Toopher has. I've never used LastPass but I'll go ahead and check that out too, thanks for the info.
smholloway
0%
100%
smholloway,
User Rank: Apprentice
2/7/2014 | 10:55:29 AM
Re: Two factor is useful after the data breach
@BGordon1 I think the concept of invisible authentication is a bit tricky because no one else is doing it. Toopher can automate authentication requests based on your location so that future requests from the same location are invisibly approved. For example, if you're logging into your bank's website from your home computer, the bank would ask Toopher to authenticate, Toopher would ping your phone, and your phone will respond for you (assuming you've chosen to automate the same request in the past); your bank logs you in without you having to type in a one time password or any of that nonsense. It's still a second factor--it's just invisible. The Toopher site might explain it better than I can: https://www.toopher.com/.
M_Gordon
100%
0%
M_Gordon,
User Rank: Apprentice
2/7/2014 | 10:41:17 AM
Re: Two factor is useful after the data breach
@BGordon1

I use Toopher with LastPass and absolutly love it! What they mean by invisible is their automation feature. Toopher uses location awareness of your smartphone to automate authentication so that you don't have to take any extra steps - like having to type in any passcodes to complete the authentication process. It is the most user friendly 2fa I have experienced. Check out this video... it helped me better understand what Toopher does. 

http://www.youtube.com/watch?v=k78xDTpy7PU
Beck
50%
50%
Beck,
User Rank: Apprentice
2/7/2014 | 10:33:11 AM
Re: Two factor is useful after the data breach
What exactly do you mean by invisible? Does Toopher remember your credentials or cookies and automatically log you in on your mobile device? I could see a lot of holes in that security. Excellent point about the post-breach security though. I definitely agree that 2fa is an important step.
SaneIT
50%
50%
SaneIT,
User Rank: Apprentice
2/6/2014 | 8:28:05 AM
Re: Beyond authentication
Yes I believe that we should view it as a good practice but we should not rely on authentication as the sole source of protection.  A majority of data loss/misuse comes from internal sources so part of the battle has to be monitoring and swift action when irregularities are detected.
<<   <   Page 2 / 4   >   >>
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
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7407
Published: 2014-10-22
Cross-site request forgery (CSRF) vulnerability in the MRBS module for Drupal allows remote attackers to hijack the authentication of unspecified victims via unknown vectors.

CVE-2014-3675
Published: 2014-10-22
Shim allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted DHCPv6 packet.

CVE-2014-3676
Published: 2014-10-22
Heap-based buffer overflow in Shim allows remote attackers to execute arbitrary code via a crafted IPv6 address, related to the "tftp:// DHCPv6 boot option."

CVE-2014-3677
Published: 2014-10-22
Unspecified vulnerability in Shim might allow attackers to execute arbitrary code via a crafted MOK list, which triggers memory corruption.

CVE-2014-4448
Published: 2014-10-22
House Arrest in Apple iOS before 8.1 relies on the hardware UID for its encryption key, which makes it easier for physically proximate attackers to obtain sensitive information from a Documents directory by obtaining this UID.

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.