Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint //

Authentication

5/1/2014
11:00 AM
Garret Grajek
Garret Grajek
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
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
Threaded  |  Newest First  |  Oldest First
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.
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".

   
Commentary
How SolarWinds Busted Up Our Assumptions About Code Signing
Dr. Jethro Beekman, Technical Director,  3/3/2021
News
'ObliqueRAT' Now Hides Behind Images on Compromised Websites
Jai Vijayan, Contributing Writer,  3/2/2021
News
Attackers Turn Struggling Software Projects Into Trojan Horses
Robert Lemos, Contributing Writer,  2/26/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: George has not accepted that the technology age has come to an end.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-26814
PUBLISHED: 2021-03-06
Wazuh API in Wazuh from 4.0.0 to 4.0.3 allows authenticated users to execute arbitrary code with administrative privileges via /manager/files URI. An authenticated user to the service may exploit incomplete input validation on the /manager/files API to inject arbitrary code within the API service sc...
CVE-2021-27581
PUBLISHED: 2021-03-05
The Blog module in Kentico CMS 5.5 R2 build 5.5.3996 allows SQL injection via the tagname parameter.
CVE-2021-28042
PUBLISHED: 2021-03-05
Deutsche Post Mailoptimizer 4.3 before 2020-11-09 allows Directory Traversal via a crafted ZIP archive to the Upload feature or the MO Connect component. This can lead to remote code execution.
CVE-2021-28041
PUBLISHED: 2021-03-05
ssh-agent in OpenSSH before 8.5 has a double free that may be relevant in a few less-common scenarios, such as unconstrained agent-socket access on a legacy operating system, or the forwarding of an agent to an attacker-controlled host.
CVE-2021-3377
PUBLISHED: 2021-03-05
The npm package ansi_up converts ANSI escape codes into HTML. In ansi_up v4, ANSI escape codes can be used to create HTML hyperlinks. Due to insufficient URL sanitization, this feature is affected by a cross-site scripting (XSS) vulnerability. This issue is fixed in v5.0.0.