You Can’t Fix Authentication Without Fixing Access

Think of the last time you logged into your network. Let’s assume that you used a traditional VPN, with a traditional IAM scheme underneath. This isn’t a bad assumption, because 25% of all internet traffic goes over a VPN. If that is in fact the case, your login process probably looked something like this:

1. Navigate to a designated URL
2. Get prompted to input your username and password
3. Input your username and password
4. The VPN checks the hash of your password against its database
5. If the password is correct, the server may authenticate you with 2FA
6. (Even if they do, some forms of 2FA are extremely weak)
7. Assuming you authenticate correctly, you’re in the network

Have you noticed the point in this workflow that should scare you? It’s step two. At that point in the workflow, you’re not logged into the network yet, but you already have access to it. There’s a great deal that an unscrupulous individual could do with this access – and it’s the reason why authentication is broken.

What Can a Hacker Do with Your Login Page?

Answer: many things, none of them pleasant.

First of all, one of the unpleasant things a hacker can do with your login page is find it. Technically, the login page for a private network shouldn’t be known to anyone besides its users. In actuality, the necessities of traditional network design forces administrators to place the login page outside of the DMZ, in front of the firewall. This makes it possible for an attacker to scan the publicly-available internet for your network presence.

Sponsorships Available

Sponsorships Available

Sponsorships Available

This lets hackers do a number of things. The easiest thing for them to do is scan open ports on the network. This lets them find additional attack surfaces, look for exposed databases, and find other low-hanging fruit. If they’re lucky, some devices or services they find exposed on your network may not even be protected by a password. This happens even in organizations that should know better – in one case, a New York airport found that their servers had been unprotected for nearly a year.

After finding exposed attack surfaces, hackers can exploit them using several different techniques. The easiest is credential theft. The second easiest is code injection – finding ways to execute code on your login server by inserting code into your login form, contact form, and more. The last method is to simply wait – to passively monitor your web presence until you make an exploitable mistake. This method is nearly foolproof, and it only works because we provide access to users before we authenticate.

How Do We Fix Access?

To fix access, you need to authenticate your users before they see a single byte of your data. Once they’re in your network, you still need to treat them as a potential attacker. You should never let outside users inject code into your network – data should only flow from the inside out. How do you accomplish this?

Reverse Access Technology, patented by Safe-T, vets a user before they can access any part of your data. This system creates reverse proxies that sit in the DMZ and contain all the information that’s necessary for a frontend app or user to navigate throughout the network. When used in concert with a zero-trust network, the result is an architecture where the users navigate a sandbox that prevents lateral movement.

Although your users may not notice anything different, your attackers will. Reconnaissance, code injection, and even credential theft all become dramatically less effective. Once deprived of an attack surface to monitor, hackers will almost inevitably move on to a softer target – saving administrators from a whole lot of difficulty. Want to learn more? Contact Safe-T today for a free trial.