Endpoint // Authentication
5/1/2014
11:00 AM
Garret Grajek
Garret Grajek
Commentary
Connect Directly
LinkedIn
Google+
RSS
E-Mail
50%
50%

How To Avoid Sloppy Authentication

Viewing authentication as a process, not simply as an encryption or algorithm, is the key to defending corporate resources from attacks.

It’s always obvious in hindsight review of the impact of a major bug like Heartbleed that something was missed. Hackers like it when the authentication deployment and security experts build sloppy authentication. The sloppiness generates vulnerabilities and thus the vector(s) for attack.

Common myths state that website hacks are the result of the breaking of authentication algorithms or the stealing of authentication seeds. But none of the major notable hacks, such as Living Social, Target, SnapChat, or Heartbleed have provided any truth to these misconceptions.

Instead, hackers attack the enterprise rather than the algorithm. Hacks are not assaults on the authentication algorithms. Simply buying new tokens (or SMS systems or PUSH two-factor systems) is not going to remove hackers, because the attacks are on the entire authentication system. We must look at authentication as an entire process, not just as an encryption or algorithm. This way, any organization can confidently secure access to all of its resources. 

When looking at authentication as an entire process, you find that it involves the issuance of authentication credentials, the collection of credentials, the validation of the credentials, and finally, the assertion to the target: 

  • The issuance of authentication credentials. This is one of the sloppiest parts of the authentication process as it continually consists of embarrassing procedures, including extensive helpdesk assistance, contractors, and lack of automation. Instead, the two-factor credential should be distributed to the user without helpdesk involvement, without contractors, and as fully auditable and repeatable.
  • The collection of authentication credentials. How many reports of cross-site scripting and SQL injection do we need to occur until we finally realize that authentication collectors should not be coded? The coding of the collection credential providers, whether single or two-factor, is a constant source of hacker delight. Custom coding, by its very nature, is a target for hackers. By how many quality assurance tests, peer reviews, and hundreds of similar installs has that code segment been reviewed?
  • The validation of authentication credentials. The validation of authentication credentials is another point of implementation where authentication integration has been consistently sloppy. What does it matter if your authentication algorithm is the latest commercial or non-commercial algorithm (Silent Circle, Tails, OTR, TrueCrypt, etc.) if the way in which we are communicating with the membership/profile provider is handled in a careless manner? Enterprises simply should not allow multiple authentication parties to access the key data stores. Furthermore, synching and migration of user data, especially to offsite locations, adds to the mess.
  • The SSO assertion to the target. This is the last and most key point. Most solutions think that sending a red light/green light signal for the identity is enough; and that the problem of asserting via single sign on (SSO) to the final resource (web, network, cloud, or mobile) is some integration outside of the authentication flow. Looking at authentication in such a limited way has no foundation in logic, yet the majority of solutions in the marketplace do just that.

This key step in authentication is often left to a highly vulnerable form post or other sloppy form of SSO assertion. But why shouldn't the authentication solution also include in its process the assertion to the web resource, the network gateway/VPN, the cloud resource, and the mobile application?

While there are technologies that combine all of the mechanisms of authentication into a single solution to ensure the integrity of the final authentication process (disclosure: SecureAuth offers one such solution), enterprises can also incorporate standalone two-factor/SSO solutions, or conduct the full code reviews, penetration tests, and crypto validation to refine their authentication process and deliver a complete solution to mitigate attacks.

The bottom line is that hackers will keep feeding off misguided and sloppy authentication deployments. It's up to us in the security profession to start mandating and implementing authentication solutions that address, not just the authentication algorithm, but the process as a whole. By centralizing the authentication and assertion procedures and removing all untrusted human contact from the system, organizations can more efficiently mitigate hackers.

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
GarretG022
50%
50%
GarretG022,
User Rank: Apprentice
5/15/2014 | 8:28:53 PM
Re: critical requirements
What is detailed, is correct and effective way to validate the authentication.   And the real key is, once the identity is validated, to insure that this identity is delivered to ALL the relying parties:   Web Resource, Thick Apps, Network Resources, Cloud Apps.    

The solution to this is a 2-Factor solutoin (utilizing strong authentication, as detailed) and then cryptographically assrt, with bi-lateral confirmation to all relevant resources.

Otherwise the hackers just attack where the authentication is done "sloppily".

   
macker490
50%
50%
macker490,
User Rank: Ninja
5/2/2014 | 8:05:09 AM
critical requirements
critical requirements of authentication:    recognition, integrity, security.

authentication must be valid 1 time only: on the instant transaction.   not like a cfredit card number which is used over, and over and over again.

authentication must be recognizable: i.e. it must be possible to verify who authored the authentication i.e. who made the signature.     attacker cannot create forgeries.

authentication validates the integrity of the transaction it is affixed to.    i.e. if attacker attempts to alter the transaction or substitute a different transaction he will invalidate the signature (integrity)

PGP or GnuPG provides these capabilitites as well as encryption (security).    this is proven software; there is no need to re-invent the wheel.   just learn to use it.

note

all computer security depends on a secure operating system.     these are available although not commonly used.
More Blogs from Commentary
InfoSec’s Holy Grail: Data Sharing & Collaboration
Despite all the best intentions, cooperation around Internet security is still a work in progress. Case in point: Microsoft’s unilateral action against No-IP.
Phishing: What Once Was Old Is New Again
I used to think the heyday of phishing had passed. But as Symantec notes in its 2014 Internet Security Threat Report, I was wrong!
Dark Reading Radio: Data Loss Prevention (DLP) Fail
Learn about newly found vulnerabilities in commercial and open-source DLP software in our latest episode of Dark Reading Radio with security researchers Zach Lanier and Kelly Lum.
The Perfect InfoSec Mindset: Paranoia + Skepticism
A little skeptical paranoia will ensure that you have the impulse to react quickly to new threats while retaining the logic to separate fact from fiction.
Weak Password Advice From Microsoft
Tempting as it may seem to do away with strong passwords for low-risk websites, password reuse is still a significant threat to both users and business.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2627
Published: 2014-08-01
Unspecified vulnerability in HP NonStop NetBatch G06.14 through G06.32.01, H06 through H06.28, and J06 through J06.17.01 allows remote authenticated users to gain privileges for NetBatch job execution via unknown vectors.

CVE-2014-3009
Published: 2014-08-01
The GDS component in IBM InfoSphere Master Data Management - Collaborative Edition 10.0 through 11.0 and InfoSphere Master Data Management Server for Product Information Management 9.0 and 9.1 does not properly handle FRAME elements, which makes it easier for remote authenticated users to conduct ph...

CVE-2014-3302
Published: 2014-08-01
user.php in Cisco WebEx Meetings Server 1.5(.1.131) and earlier does not properly implement the token timer for authenticated encryption, which allows remote attackers to obtain sensitive information via a crafted URL, aka Bug ID CSCuj81708.

CVE-2012-6651
Published: 2014-07-31
Multiple directory traversal vulnerabilities in the Vitamin plugin before 1.1.0 for WordPress allow remote attackers to access arbitrary files via a .. (dot dot) in the path parameter to (1) add_headers.php or (2) minify.php.

CVE-2014-2970
Published: 2014-07-31
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2014-5139. Reason: This candidate is a duplicate of CVE-2014-5139, and has also been used to refer to an unrelated topic that is currently outside the scope of CVE. This unrelated topic is a LibreSSL code change adding functionality ...

Best of the Web
Dark Reading Radio