Having spent my whole life coding, implementing, developing, and patenting authentication solutions, I think I have the right to say: “that stuff doesn’t work.”
That is, if the criteria of “work” is that the user identity processed by the authentication solution actually passes a 100% reliable, trustable identity to the relying party – no, this is not “working”.
Sure, we can prove (and I have done this thousands of times in my career) that the validation portion of the authentication process “works.” That is, we can mathematically and empirically prove that the entity being collected by the auth mechanism MATCHES the values within the relying party’s data store. (Be it password, one-time password or “OTP”, X.509 cryptographic exchange, biometric, gait, mobile push value, facial scan, etc.)
Yes, the “auth” process can be validated and show that the technical credential validation system is “working.”
But let’s ask our hacker friends, the white hats and the grey and black hats, whether these identity validation tools are keeping them from achieving their results.
The answer is: Hardly.
Isn’t Authentication Enough?
To the product/business owner, authentication is not just the “friction” of the authentication, but the actual entire process of validating that user identity that we authenticated is the same user consuming the IT resource.
The industry tries to distract the audience from the real problem by hypnotizing the market with the “shiny object” – e.g.: "look at my how many vectors I collect in my facial recognition model! The number is bigger than my competitor’s!" But the problem is still growing.
For example, phishing attacks remain the most common forms of identity theft. Information gained from social harvesting and the user themselves allows hackers to build up a great profile to use, in order to go after any weak points around the user’s security measures.
Where Does This Authentication Process Come Up Short?
Let’s count the ways.
The actual form/data collector for the resource can be compromised. An example: in a web app, the page that accepts the credentials can be compromised in order to route the credentials to a malicious attacker or hacking tool. This is often called man-in-the-browser (MitB) or some other form of “spy” or nefarious credential collector mechanism in the authentication process.
In addition, even if the authentication credential is safely collected, it does not mean that an attacker is stopped from snatching the credential in the auth lifecycle from collection to validation. This state is often called a network or cloud-based man-in-the-middle attack, and it’s quite common. (The latest bluetooth-based BlueBorne attacks are a recent example of an attack that utilizes man-in-the-middle workflow.)
In addition, all the nefarious Wi-Fi and other compromised network attacks are simply efforts to “grab” valid authentication data in order to aid impersonation attempts by the attacker. The reality is that in our modern world, many employees will be working on the road, and connecting to the airport or coffee shop Wi-Fi, which is a well known, easy tactic attackers use to compromise their connections.
For the Sake of Argument, Let’s Assume That the Data is Collected Securely
Even if the data is collected securely, and passed securely to the authentication party – who is to say the actual authentication apparatus or service is valid? These authentication servers and services are just IT resources, which are under the same level of attack as every other part of the IT system. Leaks, exposures, and bypasses of these services are well documented. Here are some real-world examples:
- Russian Hackers use VOIP services to bypass fraud verification
- Hackers Use SS7 Telephony Flaw to Defeat Two-Factor Authentication
Lastly, after a secure authentication has been conducted from user-to-service, the session itself can be stolen and re-used. These session attacks are often used in MitB and session hijacking (as testing lab S21sec, explained to the BBC). These attacks take advantage of the client/server architecture of IT resources and “grab” the identity session ticket that is passed between the two parties to retain the identity. These session tickets are often vulnerable to brute-force attacks, as was revealed by the GitLab vulnerability.
User Authentication Solutions Won’t Solve All Your Identity Problems
Bottom line: don’t place too much faith in the new, “latest and greatest” auth solution. (Example: Apple’s switch from fingerprint authentication to facial - it never ends!) Auth just gets the enterprise out of the end zone, but it’s a long way to go to the goal line of user security.
Enterprises have to be vigilant at the gate and then vigilant at every step of the way, as users sign in to access the resources they’re after.
Checks on both the validity and the functionality of these identities are required. We are becoming very good at the user authentication process, but we’ve yet to find a way to understand the user’s behavior and conduct after the initial authentication.
Stay tuned for more updates on this topic. In the next blogs in this series of Identity articles, I’ll be discussing:
- How we improve on this failed authentication model
- How to create tools that address the “real identity” issue: identifying the user at the front gate and throughout his journey throughout our IT castle. The real adventure is following the user AFTER he passes the moat and enters the gate.
Yours in identity,
Garret F. Grajek,
VP of Identity at Cylance.
