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.
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.
At a conference, your identity is verified at arrival and a badge (credential) is issued. This gives you access to different facilities based on the type of your credential. Once inside the building, your identity is no longer verified, that initial verification is fixed in the credential and it is considered indefinitely (throughout the conference) valid.
The two flows, issuing the credential and validating it, are separate. Credential issuing does not know if upon failure you will attempt to sneak in. If you do manage sneak in, and you get caught without a credential, they don't know whether you are fraudulently there or just haven't been through an identity verification yet. Neither flow can take action against you.
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.
Credentials are not strongly coupled with identity. They have a separate existence from the identity itself which creates multiple vulnerability vectors. Credentials can be shared, passed on, lost, stolen, duplicated with or without the issuer's knowledge, as part of their nature, and their safekeeping depends on the credential holder - outside of credential issuer's control.
Any attempt to reduce the vulnerabilities in the system, such as expiry, re-validation, et cetera, adds operational elements and thus friction to the process, raising costs and impeding the business.
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.
You throw a party and serve drinks and food to your friends. Every time you hand over a treat or bump into somebody, you inevitably verify their identity, which is unambiguously hard linked with their physical body and can only be in one place at one time.
Simply being present (in proximity) implies continuous identification. This creates a binary state where one either is validated at every moment, even if they take no action, or one is not present, in which case it is impossible for them to have any effect.
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.
This binary state of clients being either identified or not being present gives you, the host, leverage. You can ensure that anybody that is present at your party is part of your trusted circle. You don't need to know who the bad guys are, you know all your friends, so you simply lock out everyone else.
Another powerful feature of identity is non-repudiation, which indirectly implies that everybody is accountable for their own expression - there is a cost to breaking rules, and they know it. A misbehaving entity can swiftly be neutralized, meaning we also neutralize all future harmful deeds from that entity.
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.
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.
Passwords and other mechanisms in the shared-secret category of authentication are a clear example of the loosest form of credential-based authentication. Their lack of limitation both in time (we do not periodically revisit identity - credential association) and scope (not limiting where they can be used) makes them susceptible to a very large spectrum of attacks.
They say a secret is no longer a secret if more than one person knows about it. This is truer for shared secrets than for any other case. Because it is shared, each party is capable to further share the secret with a subsequent party without control or even the knowledge of the other, a phenomenon that can clearly create an unknown vector of attack for both parties, in fact.
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.
Not only are shared secrets attackable by construct, but they are also attackable by thier credential nature - criminals exploiting the murky state of being present but not authenticated to poke for holes in the system, invisible and none-actionable to any defense.
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.
2FA does not change the nature of shared secrets, it does not even prevent subsequent sharing or improve visibility in case of such practices. All it does is to reduce the extent of a credential from indefinite to a smaller interval of time (typically a session), which makes leaked credentials less practical to exploit directly, but does not stop subsequent attacks once those credentials have been exposed.
Even if 2FA could fix all problems of shared secrets it is, by nature, an inline, blocking and interactive process. It requires a human operator to intervene and unblock the flow even during the legitimate flow. Given that more than 80% of the Internet traffic is automated (aka API), it is only usable in a small fraction of online interaction. It's like closing one door but leaving four others open.
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.
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.
Humans are not part of cyberspace, they cannot interact with machines directly, they delegate machines (browsers, software) to perform their action. Cyberspace is made of devices, software and other digital constructs, exclusively. This is true for legitimate users and criminals alike.
When we authenticate one actor, the human, but the action is performed by another actor, the device, we must pass the authorization from the first entity to the second, which breaks the connection with the triggering actor and defaults to a credential model.
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?
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?1) 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).
There has been talk about passwordless for quite a long time now and yet the world is still hooked on passwords. The main blame is put on people and businesses' reluctance to switch technologies, yet what the security industry fails to realize is that today's passwordless solutions are nothing more than password masking methodologies. Accounts are still associated with shared secrets, user sessions are still pegged in a token (ex Machina), APIs continue to access services with API keys; underneath, it's all credentials.
They say the choice to switch technologies are not easy, but in this case, it really is quite the opposite, it's just that security experts don't like the industry's choices.
The switch to current passwordless technologies, like Fido and CTAP (Client to Authenticator Protocol) comes with complex technical changes, which have barely become a standard and do not enjoy universal support. There is no one-way of doing things, and many critical aspects, like account recovery, do not have satisfactory answers.
It is also an exclusively human centric approach, in a world where more than 80% of the traffic is API based or automated. Most use-cases remain unaddressed and so are the majority of vulnerability vectors. The reluctance is therefore understandable, and the security industry should take it not obstinately, but rather with empathy and a sense of accountability.
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.
In a war, each day you fight to protect your life, your assets, as well as those of who you are responsible for. It is an active state that never ends: you must be continuously vigilant, ready to respond, not all of you can go to sleep at once and the next day you wake up to repeat all this, all over again. As long as you maintain defense, things work out, but the moment you let your guard down or your defenses fail to match the attack, something will inevitably get you. In a war, there is no security, which is defined as the state of not being in danger. Today's cybersecurity does not in fact enable security. It is a cyber war-machine that helps you and other organizations preserve integrity against the continuous onslaught of cybercriminals. Many will fail because today's cyber paradigms are incompatible with security.
Identity based access helps you do things differently rather than doing the same thing in different ways. Your service is now like your own private party: People you don't know can't come in, so only your friends are there (customer devices in this case), so you know everybody. You can let them do anything and watch. When you catch them doing something bad, you can kick them out forever, even call the police on them. You see how this is different from allowing all current 8B people in your house, watch each and every one of them, make sure they don't do anything they are not supposed to be doing, and when you catch them doing it nonetheless, you might just be able to stop them from going through with it, but you can't kick them out, nor can you stop them from trying something else.
With continuous identification, the paradigms work for you: most of your friends (customers) will refrain from doing something bad, even if the opportunity presented itself, because they know they will be responsible for their actions in front of you, their friends, even authorities. You now have security.
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.
Imagine the Internet as a replica of human reality but instead of humans interacting with humans there are machines interacting with machines. Like human reality, imagine each machine as being unique, having an unchangeable identity that is inescapably present in every interaction so a machine at the receiving end of the action can recognize the source, just like you inevitably recognize your friends when they interact with you.
We are now in identity mode. A fundamentally different paradigm where credentials, tokens or shared secrets are no longer needed, the unavoidable security loopholes of passing them from one flow to another are nonexistent. In this mode, the acting entity is inescapably recognized simply by opening a connection (the equivalent of being present and ready for interaction). It is why we call it identification (establishing identity) and not authentication (establishing validity of an identity claim)
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.
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.
FOLLOW US
inLEGAL
Copyright © 2024,
Identity Plus, Inc., New Hampshire, USA,
All rights reserved