How It Works,
Why Identity of Your Device is Better Than a Credential of You

One of the basic paradigms of the Internet is access. Nothing would be possible without it... Authors would not be able to create and publish content, people would not be able to consume it, and to add insult to injury, all these activities require different types of access, which services that host the content must enforce. This is known as role-based access control (RBAC), which is just a fancy name that stands for making sure that different people have different levels of access - ability to perform select actions - based on their relationship and classification with the resources they need access to. This obviously requires that we have the capacity to distinguish between people. I say obviously, because in the day-to-day human interaction this is so basic and common sense that we don't even realize it's happening, but when we introduce indirect elements alongside people, this becomes an actual problem we need to solve.

Speaking in terms of physical reality, which is where all information technology practices are adopted from, there are many mechanisms to obtain the identity and/or the relationship of a party with respect to a resource - think keys of all sorts, badges, IDs, security guards, dogs, et cetera - however, when we think from a security perspective, not all identity verification are built equal. Some are direct, while others are indirect, and even though this does not seem such a big deal at first glance, there are in fact physical constraints that play a fundamental role in determining the level of precision and control one can exert when employing either category of mechanisms, and that degree of precision and control has an inconspicuous but profound impact on access control and therefore security in general.

The reason I briefly jumped back to reality is that across the Internet (interestingly, not all information technology systems) every identity/role verification is based on indirect mechanisms, which practically kneecaps our security capabilities. Security becomes hard to the point of impractical not because we are not doing enough, but because the indirect architecture will remain insecure no matter how much we do, which means the sensible course of action is not to do even more within the current set of constraints, but instead try to eliminate the constraints themselves by moving from indirect identity verification to direct identity verification.

In the following, I will explore why indirectness is ubiquitous across all current role determining processes across the Internet, what are the systemic problems of this indirectness and how we can remove ourselves from this catch 22 by re-thinking the roles of the participants in Internet interactions.

1	Credential Based Access

It's safe to assume that by now we have all heard of the concept of credentials, how bad credentials are, how leaked credentials are plaguing security, mostly within the context a of traditional login, but credentials are a much broader concept than username + password combinations. In fact, they do not even inherently require these two elements, because a credential simply refers to an entitlement given to an otherwise untrusted entity - let's call it client - by another entity who is perceived as an authority. This entitlement can now be used by client to achieve a certain level of access at a third party - let's call it service - who trusts the issuing authority. This ternary nature is what makes credentials indirect and why the validation step before access is called authentication and not identification, as we are not in fact verifying the identity of clients at this stage, we verify whether the credentials they present are authentic.

It is important to emphasize that the ternary nature is not due to the presence of the third-party, rather it is a characteristic of the process itself. As such, it remains ternary even if we remove the third party authority by having the service play both roles, issuing the credential in one flow, and then verifying it in a secondary flow. Like issuing a session token at login and then verifying the session token when the user attempts to access a certain resource: everything now depends on that session token, independent of authentication.

2	Identity Based Access

All access on the Internet is currently based on this pattern, no exception, regardless of the implementation (if it is based on user name or password or some other mechanism), which is why it is so difficult to imagine any other way of doing this. It is also why authentication has become a universal term, often incorrectly implying verification of identity.

That said, from a dynamics perspective, there is in fact an alternative to this process which involves verifying the identity of the client directly, whenever interaction happens. This is easiest to do if the service can also perform the identity verification job from the credential flow - which is the case when the authority and the service are one and the same. Regardless, the flow can also be executed with the aid of a third party as long as the service is able to ready the identity of the client. This is why we call this identity-based access.

Identity is a lot of things - how it is attributed, what it represents from a social perspective - but for now it is sufficient if we consider it at face value, its definition, as being some property that uniquely and unambiguously separates one entity from everybody else. This intrinsic characteristic of the identity - which inexorably points to the entity it describes - is topological in nature: it is not a property of the authentication process (a process taking place in cyberspace), instead it is a property of cyberspace itself (it controls how interaction in cyberspace happens). Activating this property doesn't just improve a process, such as authentication, it changes the paradigms processes operate in. It makes possible things that are otherwise physically impossible and has the capacity to shift the balance of advantage.

Enabling identity in cyberspace is not a question of improving authentication flows, these flows are ternary in nature and can never be used to directly probe someone's or something's identity. To enable identity we have to re-evaluate how we model identity in cyberspace. Let's see why and how.

3	Simple Authentication - Passwords

We know passwords are bad, but in order to understand just how bad they are and why, we need to look at how password-based authentication maps in the direct vs. indirect identity verification dynamics. Username and passwords are configured at sign-up, and then later they are used to perform an authentication and issue a session token based on which resources are accessed. Even if we consider that initial sign-up process an identity validation, which it isn't, but in many instances that is not mandatory (true identity of the person is not a pre-requisite to providing a service as long as we can ensure the same person returns), the sign-up process (credential issuing) and authentication (credential validation) are still separate flows, and authentication (access token issuing) and access restriction (token validation) are yet again separate flows, which gives password based authentication a second degree of indirectness: indirect squared, if you will. If indirect strips you, the host, of leverage, you can imagine what leverage you retain with multiple levels of indirectness, which gives you a sense why passwords are bad. It's not just because people use them in a bad way, which most often is being blamed on, but because the whole construct is architecturally flawed.

No matter how many bells-and-whistles we attach to passwords in the online space, they will never be able to transfer leverage from the client to host, meaning the attacker will always have the upper hand - it will be exponentially easier to attack than to defend.

4	Classic 2FA - Credential Confirmation

2FA has been for a while considered to be the solution to the problems credentials suffer from, but it quickly became obvious that it is neither simple to use or a complete solution, which is a sort of a double-whammy, even though it does offer some levels of protection against some weaknesses induced by passwords. A lot of SOMEs considering the levels of effort, but this should not come as a surprise if we were to analyze 2FA from a geometry perspective (direct versus indirect). 2FA is exactly what the name says - two factors of authentication, two distinct credential issuing processes with their respective credential validation steps chained together.

While having two credentials on an entrance gives some level of security in case one of them got compromised, the ternary credential nature remains unchanged. In fact, just as in the case of passwords, 2FA retains its second degree indirectness from a geometry perspective, and in fact the two factor element only extends on one of these levels. The validation of the session token, the temporary credential, is not re-visited. Because of these organic limitations, 2FA protects against a tiny fraction of the attacks Internet services are exposed to, a small difference compared to simple credential (as highlighted in the adjacent image) given the amount of added difficulty that hits legitimate participants. Additionally, it introduces a premise into the authentication process - that humans are present in all Internet interactions - which is obviously false for the vast majority of the traffic on the Internet. Interestingly, the fact that such false premise was considered in the first place as being acceptable, speaks greatly about the bias we have when it comes to elements of cyberspace, which tends to overestimate the role of humans, at the expense of other actors, and very much clouds our understanding of how cyberspace really works.

5	Authenticating People Forces Use of Credential

Humans obviously play an important role when it comes to the Internet, ultimately the very existence of the Internet is owed to humans and its purpose is to serve human needs, make our lives better, but when it comes to the construct of cyberspace itself, the architecture, the elements and the connections between those elements, the role of humans is unworldly, supernatural if you will. We are like gods to Cyberspace, influencing its existence, its shape, construct, adding and removing elements from it at our own discretion, deciding what these elements do and how they can do it, but we are not elements of it. We always interact with it, and any element from it, indirectly. As philosophical as this may sound - a pure intellectual exercise - this indirectness has in fact a profound practical limitation when it comes to interaction in cyberspace. Because indirectness is part of the construct, any attempt to identify a human in cyberspace will inevitably be indirect. Ergo, limited to credential dynamics.

This indirect nature of cyberspace in relation to humans has otherwise a massive benefit, in fact it is one of the biggest benefits that it brings: it enables people to detach themselves from the processes that take place across the Internet and allows machines to operate on their own. Indeed, all interaction (100% of it) across the Internet happens between two machines, never between a human and a machine, and those situations in which we find ourselves being the puppet master pulling the strings - guiding every action a computer should take by literally pushing buttons and telling browsers and applications what to do - are the minority of situations. Most of the communication (interaction) on the Internet happens between digital constructs (devices or software) that are preprogrammed with sets of routines they should execute in response to events. This is how they remove the burden from humans, by eliminating the need for them to be present, so how does authenticating humans fit in this landscape?

6	Passwordless Authentication - Temporary Credentials

Within this frame of analysis, passwordless authentication - the latest and greatest in account access security - is nothing but an increment to previously developed 2FA technologies which unsurprisingly continues to fail to consider both the indirectness of human authentication and the necessity of the system to operate in total absence of humans. It eliminates the password because passwords are bad (are they really? ¹) but leaves everything else unchanged. The sign-up is till disconnected from the authentication, the authentication status is still contained in a session token, the still system depends on a human to be present and the vast majority of attacks can still be performed in the limbo-state (the state of being present but not authenticated).

7	Authenticating Device Enables Use of Identity

If indirectness - which in case of human authentication is caused by the absence of humans in many use-cases and the physical incompatibility of humans with cyberspace - is the problem, then it stands to reason that we should re-design our authentication and identity models with a focus on something that is continuously present in cyberspace. In human reality, humans are the objects of identification - because they are the agents that perform/trigger actions - in cyberspace, the equivalent of that would be devices, software or the digital entities who perform actions (we can collectively call them devices). If one device, the host, can recognize (read the identity) of another device, the client, then we suddenly find ourselves in an environment with different paradigms that no longer limit us to credential based access. This is not an incremental benefit, this shifts the position of leverage from attackers to defenders, enables us to trade defense for peace and makes possible security without friction.

8	Identity Based Access - Continuous Identification

When banking online, the reason you need to approve a transaction is because the credential that was issued to your browser at login cannot be considered safe. Any number of bad things can happen to it from the moment of authentication and to the moment of the transaction, just like you could lose the key to your house, or someone can "borrow" it and copy it without your knowledge. It is unpleasant, but necessary, therefore in credential mode more validation translates into more friction. Continuous validation would require infinite friction, basically every call your browser makes (hundreds at each click) would have to accompanied by a login - sadly even the login calls, which makes it recursive and thus infinite.

That is not the case with identity based access, because in identity mode, the validation of identity is part of the access. If there is no identity, there is no access, so instead of having infinite friction to achieve maximum security, we in fact end up with zero friction and maximum security. This is no magic, just well designed architecture.

In the device identity model, the host gets to identify the client machine when the communication channel opens - that is, before it accepts any action from the client, and before it sends any information - so host services know ahead of time who is knocking at the door and can pick and choose who they communicate with. As a service, your application is no longer exposed to all 7 billion unknown devices on the Internet, only to your customers. You don't care about botnets, unless one of your customers runs one on your service, but then you know exactly which one because even if you have vulnerabilities (obviously not a good thing to have, but often inevitable) they are only exposed to your customers, and each customer is accountable for their actions, and they know it.

9	Distributed Trust - Accountable Identities

You are probably wondering that if identity based access and device identification is so powerful, how come something as mundane as a reflected cross site scripting is not covered. This is because in a reflected XSS the attacker does not target the host. It targets the customer, with an attack that is not stored on the host, exploiting a vulnerability the host has. It is indirect, so the complete picture lies outside of the observability capabilities of any one host when they operate in isolation.

That said, even a reflected cross site scripting has to be stored somewhere, on some service, and if the vulnerability is yours, as a host, then by identifying devices you can be sure the attacker is one of your customers (otherwise they cannot discover vulnerabilities because they cannot access your service), so the complete picture is in the larger system, and together, by cooperating, we can correlate that information, and when we get there, we will have the power to oust criminals from cyberspace, much like we isolate criminals in reality. At that point, the Internet will be truly secure. It is just a matter of time.