Endpoint // Authentication
11:00 AM
Garret Grajek
Garret Grajek
Connect Directly

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
Newest First  |  Oldest First  |  Threaded View
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".

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.


all computer security depends on a secure operating system.     these are available although not commonly used.
Register for Dark Reading Newsletters
White Papers
Current Issue
Dark Reading Tech Digest September 7, 2015
Some security flaws go beyond simple app vulnerabilities. Have you checked for these?
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-10-09
Simple Streams (simplestreams) does not properly verify the GPG signatures of disk image files, which allows remote mirror servers to spoof disk images and have unspecified other impact via a 403 (aka Forbidden) response.

Published: 2015-10-09
The Telephony component in Apple OS X before 10.11, when the Continuity feature is enabled, allows local users to bypass intended telephone-call restrictions via unspecified vectors.

Published: 2015-10-09
IcedTea-Web before 1.5.3 and 1.6.x before 1.6.1 does not properly sanitize applet URLs, which allows remote attackers to inject applets into the .appletTrustSettings configuration file and bypass user approval to execute the applet via a crafted web page, possibly related to line breaks.

Published: 2015-10-09
IcedTea-Web before 1.5.3 and 1.6.x before 1.6.1 does not properly determine the origin of unsigned applets, which allows remote attackers to bypass the approval process or trick users into approving applet execution via a crafted web page.

Published: 2015-10-09
The Safari Extensions implementation in Apple Safari before 9 does not require user confirmation before replacing an installed extension, which has unspecified impact and attack vectors.

Dark Reading Radio
Archived Dark Reading Radio
What can the information security industry do to solve the IoT security problem? Learn more and join the conversation on the next episode of Dark Reading Radio.