Perimeter
11/9/2012
03:01 PM
Gunnar Peterson
Gunnar Peterson
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Puzzle Logic

Authentication is an enduring mystery, but solving authorization puzzles may be a better use of your security resources

Access control is all about who are you and what you are allowed to do. As it turns out, one of those questions is easy to reliably answer, and the other basically impossible. Malcolm Gladwell wrote on the difference between puzzles and mysteries:

"The national-security expert Gregory Treverton has famously made a distinction between puzzles and mysteries. Osama bin Laden’s whereabouts are a puzzle. We can’t find him because we don’t have enough information. The key to the puzzle will probably come from someone close to bin Laden, and until we can find that source bin Laden will remain at large.

The problem of what would happen in Iraq after the toppling of Saddam Hussein was, by contrast, a mystery. It wasn’t a question that had a simple, factual answer. Mysteries require judgments and the assessment of uncertainty, and the hard part is not that we have too little information but that we have too much. The C.I.A. had a position on what a post-invasion Iraq would look like, and so did the Pentagon and the State Department and Colin Powell and Dick Cheney and any number of political scientists and journalists and think-tank fellows. For that matter, so did every cabdriver in Baghdad."

In access control, we try to solve the "who are you" question with authentication and the "what are you allowed to do" question with authorization. However, the authentication process is really just an attempt to solve a mystery: We try to stitch together some details and guess whether the person on the other end of the http connection matches the record in the user directory. This cannot be done reliably or cost-effectively. Consider this list of 25 different authentication contexts supported by SAML (PDF) alone:

  • IP
  • IP Password
  • Kerberos
  • Mobile One Factor Unregistered
  • Mobile Two Factor Registered
  • Mobile One Factor Contract
  • Mobile Two Factor Contract
  • Password
  • Password Protected transport
  • Previous Session
  • Public Key X.509
  • Public Key PGP
  • Public Key SPKI
  • Public Key XML Digital Signature
  • Smartcard
  • Smartcard PKI
  • Software PKI
  • Telephony
  • Telephony Nomadic
  • Telephony Personalized
  • Telephony Authenticated
  • Secure remote password
  • SSL/TLS Client Authentication
  • Time Sync Token
  • Unspecified

That's a lot of guesswork! The Infosec community, which has been underfunded since its inception, has come up with dozens of ways to guess at who a user is. It's an important problem, no doubt, but one seemingly without an answer.

Meanwhile, investment in authorization (solving puzzles) has languished. Sure, we have advanced from access-control lists to role-based access control, and some leading-edge companies are looking at attribute-based access control and standards like XACML. Still, the resources devoted to attempts at illuminating authentication mysteries dwarf solving authorization puzzles.

The basic function of an authorization decision maps the subject user requesting access to a policy governing what type, if any, access they have to the resource and under what conditions. It's fair to point out that the authorization decision can never be stronger than the initial authentication step -- if your authentication is spoofed, all bets are off -- but even though authorization can't be stronger than authentication, it can be weaker!

This matters because while both authentication failures and authorization failures lead to vulnerabilities, authentication vulnerabilities can only be reduced (by more accurate guessing), authorization vulnerabilities can be removed, zeroed out. Yet authorization vulnerabilities persist, and so whole classes of bugs, like Cross Site Request Forgery, live on and will until more resources are devoted to solving puzzles.

Improving authentication is about improving the quality of guesses. Authentication isn't perfect, but does SAML need a 26th or 27th different type of authentication context? In contrast, wouldn't it make more sense to work with what we have and ensure the scope, granularity, and coverage of our authorization are properly fitted to the resources we need to protect?

Gunnar Peterson is a Managing Principal at Arctec Group

Gunnar Peterson (@oneraindrop) works on AppSec - Cloud, Mobile and Identity. He maintains a blog at http://1raindrop.typepad.com. View Full Bio

Comment  | 
Print  | 
More Insights
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.