< Shades of Gray in Online Authentication ( Part 1 )

Shades of Gray in Online Authentication ( Part 2 )

July 1, 2018 / Stefan H. Farr

Based on where it is performed

Probably the least understood aspect of authentication is that it can be performed in different parts of the networking protocol stack and like every other aspect, each has advantages, disadvantages and great deal of confusion. To understand the distinction, let's start by looking at a few examples which are fairly familiar but we don't really look at them as authentication in the normal sense.

Router to router

One of the most popular protocol where such authentication happens is Wifi. To connect to a wifi router your computer needs to know the wifi id (which most often is broadcasted by the router) and the passphrase. Essentially, anybody who knows the passphrase can connect to the router, which means this type of authentication has very little attribution and identity elements in it, but it does ensure relatively well that nobody can intercept the radio waves and listen in on the communication. Being used in a data link layer protocol, by placement (where it is performed) is situated on Layer 2 OSI.

If the router also uses MAC address filtering (not very secure) or Network Access Control (NAC) authentication (PKI based & very secure), then this authentication can also provide good device attribution, which means only select devices in the world can connect to the router. That said, it has a very narrow scope, in the sense that it can only take you to the nearest router. In a similar way, the GMS mobile protocol identifies the phone (device) within the network by ways of a SIM card, but just the same, it can only take you (authentication wise) as far as your mobile carrier. This is the limitation of any authentication placed in the data link layer.

Address to address

Another popular protocol that involves authentication and encryption is the VPN. Although it is regarded more like an anonymizing protocol in the popular culture, the VPN is in fact a very strong point to point (IP Address to IP Address) privacy protocol. It essentially creates an encrypted communication tunnel between two endpoint which may be far apart, many routers apart (so to speak). To achieve this, the protocol was built upon the IP protocol, which puts it on Layer 3 OSI, or the network layer. In a multi-tenant environment, VPN providers will use PKI, to identify the connecting devices (like your computer or mobile phone for example), which provides extremely strong device authentication, but the VPN protocol is very rigid. Although it can use PKI to authenticate your device, it can only connect your computer to another network endpoint (aka a VPN bride). This makes it useful in situations when one wants to connect to local area networks in a secure way, or you want to hide your IP address (the tunneled connection masks your IP address behind the VPN provider's ip address). However, it is not useful to log into applications, because everybody who is coming from behind a VPN, would essentially have the same identity.

Application to application

One of the least known authentication mechanisms is the 2 Way SSL, which uses PKI to authenticate application end-points to each-other, on transport (connection) layer, or Layer 4 OSI. Although it is fairly flexible from a technology perspective and extremely secure, logistically it proved difficult to distribute Certificates (PKI keys) at the scale needed by today's Internet, so this authentication was mostly ignored outside strict enterprise or government environments. It has been substituted with Layer 5+ (application level) authentication protocols, which are more destined to authenticate people rather than computers.

Connection level vs. application level

It's easy to notice, that as we move up in the protocol stack, the range and granularity of the authentication mechanism grows so one would be tempted to conclude that for maximum flexibility we need to authenticate as high as possible in the protocol stack:

Computer <-------- L2 -------> Router
Computer <------------ L3 ------------> Computer
Computer <---------------- L4 ----------------> Application
Human    <-------------------- L5 + ---------------------> Application

This has sadly been the mantra of authentication for many years and sure enough Layer 5 + authentications were the first type of authentications to appear. Only when the industry realized how important it is to apply authentication at lower layers, were they gradually introduced. It's a pity, because there is a fundamental distinction between Layer 5 + authentications and those below, which is Extremely (with a very big E), useful from a security perspective and an entire internet is not making use of it.

These lower layer authentication mechanisms are part of the communication protocol itself. What this means is that if there is no authentication - there is no communication either. One cannot cannot establish communication with a VPN server unless one knows the encryption key, which makes good VPN setups unhackable. Not being able to communicate with something in cyberspace, is analogous to not being able to touch something in reality. For example, you cannot templer with a locked door if it lies on the other side of Grand Canyon.

In contrast with this, layer 5 + protocols perform authentication within the application itself. Therefore anybody is free to communicate with the application even in an unauthenticated state. To put it in perspective, this would be like not having the key to a door, but the door would be within your reach, so you are free to see if there is a wide enough crack for you to fit through, if there is a week lock or somebody hid the key under the matt.

We have gotten used lately, especially in the Saas space, with applications having no perimeter defense. Indeed, with layer 5 + authentications it's impossible to create a hard line, and therefore the defense perimeter is infinitely large. Every line of code, bespoke or originating in any of the third party libraries may become the crack in your allegorical door. In a world where software is built hastily, the complexity is so great that about 80% of each software is pre-built by someone else, where the overwhelming focus is functionality and security and testing receives very little attention, the positioning of authentication in the protocol stack can make the difference between secure application and one that is potentially vulnerable at every corner. Under these circumstances, the question of where authentication happens, is in fact a question of having or not having a perimeter.

Based on "Who" or "What" do we authenticate

We often think of identity as a uniquely human trait, but in cyberspace there are many actors that perform actions and need access to resources and they are not humans: applications accessing databases, microservices authenticating to one-another, b2b services, bots, personal digital assistants, not to mention the realm of IoT devices. All these business to business actors need and perform authentication and they do so on behalf of an organization or individual, without having a human to validate such authentications.

On the opposite side of the story, we have humans (client to business), which use devices to visit online services (there is really no other way), but we consider it irrelevant to authenticate the browser/device itself, because we have the human interacting live with the service, and so the entire process is offloaded to that human. The two processes are distinct from the perspective of who "stores and presents the authentication information", but otherwise in both cases there is an unavoidable chain of dependency:

  1. There is a service storing some resource
  2. There is cyberspace actor performing the access to the resource
  3. There is a real world owner of the resource stored at the service

When using current authentication methodologies in either of the two distinct authentication cases, automated vs. user-driven, only two of these three dependencies are preserved:

  • For client to business (c2b), 1 and 3 are preserved, and we lose 2. (the device)
  • For business to business (b2b), we have 1 and 2, and we lose the human dependency

In each case we lose the capacity to observe the entire chain, and therefore the two authentication case also become two distinct authentication processes based on "who do we authenticate". The reason why the two scenarios are treated differently by the industry is because not every authentication works for both actors. By its nature, being part of the communication protocol itself, only a machine can perform a connection level authentication. If a person were to use PKI as means for authentication, they would have to perform it at application level. Conversely, it would be impossible for a device to use biometric authentication because simply it acts in the absence of the user. The same is true for multi-factor authentication, which would effectively block an automated process.

From a methodology perspective the nuances are subtle, but but they are very important from a security perspective, because they create exploitable scenarios:

  • In the c2b instance, a human, can use any device in the world to authenticate to a service, or if we put it another way, a human's identification information can be used from any device in the world to perform authentication, effectively leading to impersonation.
  • For the b2b scenario, the current de-facto authentication is the built in key (whether it is pki or a password-like token). A static key stored on the device, which do not preserve the human/organizational dependency information. Once deployed, they are difficult to change, making updates or ownership changes quite problematic.

These exploit avenues are very difficult to compensate for. Mitigations introduce great friction and in some cases they are so complicated that it is not feasible to entrust the user to managing them. This can make online systems quite vulnerable to ingenious attacks. Due to their dual nature (both clients and servers), IoT deployments are essentially crippled from both perspectives, they are forced to use "application level authentication" and "built in passwords" (both to identify themselves but also to authenticate administrators), which is why IoT security is in such dire situation. Sadly, with the increasing sophistication of attacks, the growing need for automation, AI agents and the increased need for user mobility, SaaS security is not very far behind, in the vulnerability statistics.

Closing note

There are a lot of scenarios and combinations of scenarios that come to play in online authentication and identity systems. Covering all aspects in such way that neither security or convenience is sacrificed is an arduous task and requires analyses at the deepest level, accounting for everything: technology stack, actors, processes, the data being accessed, end-point devices, and many, many more components. Luckily, there is a technological answer for everything and it only rests on our understanding of how these answers come together, to meet the process requirements without sacrificing security. My hope is that the present document will help you better understand how different authentication technologies are spread upon the technology stack in your environment, and make it easier to recognize which of them offer maximum security in the points where your processes intersect the technology stack. Hopefully this will help you ask the right questions when you pick your next vendor or help you handpick and combine authentication technologies when you build your next tool, in such way as to give you and your customers maximum security and convenience.

I am Stefan, the CTO of identityplus, a company that works on the frontiers of identity and authentication. Feel free to reach out to us with your hard questions. We cannot guarantee we'll have a solution for it, but we would certainly enjoy dissecting it.

< Shades of Gray in Online Authentication ( Part 1 )