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
Google+
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
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.
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
Breaches Are Inevitable, So Embrace the Chaos
Ariel Zeitlin, Chief Technology Officer & Co-Founder, Guardicore,  11/13/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-2916
PUBLISHED: 2019-11-15
qtnx 0.9 stores non-custom SSH keys in a world-readable configuration file. If a user has a world-readable or world-executable home directory, another local system user could obtain the private key used to connect to remote NX sessions.
CVE-2019-12757
PUBLISHED: 2019-11-15
Symantec Endpoint Protection (SEP), prior to 14.2 RU2 & 12.1 RU6 MP10 and Symantec Endpoint Protection Small Business Edition (SEP SBE) prior to 12.1 RU6 MP10d (12.1.7510.7002), may be susceptible to a privilege escalation vulnerability, which is a type of issue whereby an attacker may attempt t...
CVE-2019-12758
PUBLISHED: 2019-11-15
Symantec Endpoint Protection, prior to 14.2 RU2, may be susceptible to an unsigned code execution vulnerability, which may allow an individual to execute code without a resident proper digital signature.
CVE-2019-12759
PUBLISHED: 2019-11-15
Symantec Endpoint Protection Manager (SEPM) and Symantec Mail Security for MS Exchange (SMSMSE), prior to versions 14.2 RU2 and 7.5.x respectively, may be susceptible to a privilege escalation vulnerability, which is a type of issue whereby an attacker may attempt to compromise the software applicat...
CVE-2019-18372
PUBLISHED: 2019-11-15
Symantec Endpoint Protection, prior to 14.2 RU2, may be susceptible to a privilege escalation vulnerability, which is a type of issue whereby an attacker may attempt to compromise the software application to gain elevated access to resources that are normally protected from an application or user.