The Problem With Two-Factor Authentication

[Audrey McNeil <audrey () riskbasedsecurity com>]

http://www.darkreading.com/identity-and-access-management/the-problem-with-two-factor-authentication/d/d-id/1113697


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.

_______________________________________________
Dataloss Mailing List (dataloss () datalossdb org)
Archived at http://seclists.org/dataloss/
Unsubscribe at http://lists.osvdb.org/mailman/listinfo/dataloss
For inquiries regarding use or licensing of data, e-mail
        sales () riskbasedsecurity com 

Supporters:

Risk Based Security (http://www.riskbasedsecurity.com/)
YourCISO is an affordable SaaS solution that provides a comprehensive information security program that ensures focus 
on the right security.  If you need security help or want to provide real risk reduction for your clients contact us!