Executive Summary
Every few years, society advocates for the retirement of some technology thought to be no longer sufficient. This generation chooses to attack the password for perceived security risks. At ZKX, we make the argument that the password is not the problem, the technology behind it is.
Our technologies seek to make cybersecurity a responsibility left to be fulfilled by good technology and adequate policy, not a burden to be continually placed on the end user.
The Road to “Passwordless” is Paved with Good Intentions
This editorial, written by Chief Technology Officer, Collin Sweeney, was published by Intelligence Community News and can be found here.
Seemingly every generation or so, the technological collective suddenly bands together and aggressively advocates for the sacrifice of some technology thought to be well past its prime, all the while attempting to persuade the rest of us to help partake in the spilling of its blood in order to appease the gods of progress that abandoned us long ago. CRTs, plastic bags, incandescent lightbulbs, landline phones, Flash (etc.) all very suddenly went from enjoying the banality of existence to having full-fledged campaigns launched against them, almost all of them under the all now-too-familiar thesis: “We should all stop using [insert thing here].” Proponents of these sorts of measures often claim that these discontinuation campaigns are warranted because simply put, there are just better alternatives out there. And most of the time – that’s true: LCDs replaced CRTs, canvas bags replaced plastic, and mobile phones dominated landlines right out of market share. Surely ceasing the use of technologies well into their twilight years is a net positive, right? It leaves room for more innovation, it often raises the quality of life for consumers, and sometimes it can even help lower other costs like production or energy consumption. What’s not to like?
While these advocations for collective technology migration surely have their capital points, the most recent of these disuse campaigns have been met with a supportive fervor that is difficult to justify – not just because the would-be pariah technology is an unjust target (a victim of opportune circumstance), but also because its proposed replacements (and the motivations from the creators behind them) are suspect at best. While previous campaigns have successfully changed the course of technological consumption towards what many would argue to be a “net-plus,” a campaign centered on discontinuing the use of a service or utility that is universally still very useful could prove to be a detriment. The subject, in this instance, is the password. While advocates for these new campaigns to “kill” or “retire” the password surely hold their position(s) with the purest of motivations, the road to hell is often paved with good intentions. We contend that the password should ultimately be spared and that not doing so will only sink us lower on the cybersecurity front than we are now.
But the password is a suboptimal piece of technology, right? It is often the critical connection between the nefarious outside world and instance after instance of devastating cyber attack: the VA was compromised when a hardcoded password made its way to a public GitHub repository, and even the notorious FireEye/SolarWinds attack was leveraged, in part, by stale passwords. Indeed, password phishing is the second-most common cause of cyber breaches (and the costliest). Of course, countless others examples exist, too. So why should we hang on to a piece of technology that clearly and routinely promulgates its obnoxious shortcomings on a consistent basis?
To answer this question, we must first address how it is that the password actually works under the hood. In general, passwords, in the traditional sphere of cyber operations, are created when a user signs up or enrolls for a new platform/service/utility, etc. – usually, something that creates said user an account. On the side that manages the enrollment (commonly referred to as the “server-side”), that user-created password is stored with the organization that has custody over the account, usually in a database somewhere. At the end is the user who engages with said platform (the “client-side”), and they are free to record their password however they choose: in a password manager, written on a sticky note, or simply dedicate it to memory. Later, when the user-in-question would like to access the account associated with the organization’s platform, they are required to specify two things: the account that belongs to them (usually in the form of a username) and the password that they used at the time of that specific account’s creation, ultimately proving that they own that account.
Voila! We have now successfully mapped the high-level anatomy of a process known as password authentication – the act of proving your right to privileged access (e.g., account ownership) via some specified secret string (i.e., a password) that both the client and the server are expected to know. In dork-speak, this arrangement is referred to as symmetric, as both sides of this transaction must be privy to the same knowledge about the authenticating information (in this case, the password). This highly familiar process has been driving the execution of privileged network action since the days of ARPANET.
If you haven’t lived under a rock since the Bush administration, you most likely see or are personally familiar with the apparent security shortcomings here with password-based authentication. The password being accessible on both ends of the transaction surely is not optimal from the infosec standpoint, as an adversary (a person who wants to “get” a legitimate user’s password) now has two options to compromise the user’s password: through the user or through the server that stores the user’s password.
Through the user, we are all somewhat familiar with the tactics that can be used to glean someone’s password (thanks to the banal and, quite frankly, asinine cybersecurity “awareness training” we are all legally mandated to suffer through to some degree): social engineering, phishing, spear-phishing, etc. On the server-side, misconfigured databases or the use of stolen or leaked administrator credentials could allow a nefarious party access to a user’s password as well.
There are some commonplace protections in place, however. Clients are encouraged to use implements such as password managers and to avoid writing down their passwords or communicating their passwords to any other party in order to prevent password leakage. Similarly, servers employ practices such as salted password hashes and requiring password databases to be secured to some standardized degree to prevent password exposure. But even these implements have their shortcomings: password managers are breached all the time, and rainbow tables, massive repositories of previously- salted & hashed passwords, can be used to recover the original password from the server’s obfuscation techniques. To combat this, organizations will employ password policies that dictate things like a password’s length or certain characters it must / must not contain. But these, too, have yielded to the unstoppable procession of time and regularly reveal their own security shortcomings. Even techniques as complex as multi-factor authentication (MFA) can be attacked and breached, albeit with a higher threshold of complexity (usually).
All of the above still fails to explain why we shouldn’t kill the password. In fact, the preceding paragraph does a pretty nice job of explaining why use of the password should be discontinued. It’s insecure as all hell and adds both risk and work not just for the user that depends on the networked service but also for the organization that provides it. While the reliance on the password in the modern era certainly poses a significant threat, security in the cyber domain lives on a spectrum. On one end lives the subject of our conversation thus far, security. On the other, a lesser-known but perhaps equally important idea – usability.
In Defense of the Password
Generally speaking, the more usable something is, the less secure it tends to be, and vice-versa. Passwords, in their most fundamental form, for all of their meticulous security flaws, are usable. “Usability” is somewhat subjective as a concept, but essentially, it represents the perceived amount of friction (e.g., a stoppage or pause in a user operation or action) a process or technology imbues on a user. For example, logging into an account with my password has less friction than logging into an account with both my external MFA hardware token and a code delivered to me from an out-of-band text-messaging service. Although the latter is arguably more secure, passwords are intuitive, and people like to use them. In fact, some users are reluctant to adopt emerging technologies such as passkeys because they are not convinced that the interaction-less process is secure. That is, passwords were generally favorable to the user until policy grabbed ahold of them.
It has been known for some time that passwords do not constitute the highest standard of security when left to the exclusive devices of the creative genius known as the user (specifically those of us that are “password” or “1234” kinds of password designers). To thwart such shortcomings in password technology, certain password policies were introduced that dictated things like password length, the inclusion of special characters (e.g., ! ? #), the inclusion of capital letters, the inclusion of numbers, and the exclusion of things like your account username, simple words and phrases, and strings that resembled birthdays or other accessible bits of personal information. However, when poor policy meets poor technology, poor culture is produced – and this just leads to continued breaches or hacks, oppressive policies, user friction, and stale quarterly cybersecurity awareness training administered by a series of soulless pre-recorded videos.
So we should retain the password because it’s usable? Because people like it? This seems like a fairly weak argument for sparing the password from the sacrificial dagger of technological consumer progress. However, the thesis isn’t that the password is bad – rather, that the technology that underlies the password is bad and, ultimately, is what should be replaced. Let me explain.
Remember all the way back in paragraph four how we detailed the high-level workings of password authentication? What if we could re-engineer that underlying process without changing the password itself? What if there were a way to design out the horrendous policies we described in paragraph seven and remove specific limitations on the password – and perhaps even eliminate chunks of that cybersecurity awareness training?
User-Focused Authentication
At ZKX Solutions, that is exactly what we have designed our technologies to do. Instead of the traditional symmetric setup with both client and server needing to be privy to the password in question in some form, ZKX authentication allows only the client to retain knowledge or possession of the sensitive string via an asymmetric architecture – an arrangement where the expectations of knowledge are not equal between client and server.
In fact, ZKX authentication is so slanted in favor of the user that the server is not required to employ or hold custody over any private or authenticating information of the user or their device in any fashion whatsoever. Using ZKX authentication, users can authenticate themselves exclusively via password without the server ever learning what their password is. Similarly, if an adversary is trying to sniff out the password by eavesdropping on the user’s authentication with the server, that adversary also learns nothing about what the user’s password may be. Even if an adversary is able to glean a user’s legitimate password from them (via social engineering, for example), that adversary still would not have enough information to compromise any of that user’s accounts, as ZKX authentication requires the user’s specific device to participate in the transaction as well – effectively authenticating both user and device simultaneously.
ZKX authentication is also designed to circumvent those pesky password policies, too. When a user registers for an account or service that utilizes ZKX authentication, they are free to choose any password they wish for purposes of login – and we mean any (finally offering a reprieve for the “password” and “1234” types out there). To do this, ZKX authentication takes user-supplied passwords (non-uniformly distributed data) and transforms them into uniformly distributed data via one of our patent-pending software technologies. This even enables users to re-use the same password for different accounts, the cardinal sin of modern password authentication, as even the same passwords will appear different for each unique account registration, a user undertakes within the ZKX authentication regime. Beyond this, ZKX authentication supports non-interactive session authentication enabling users to log in with their password and re-authenticate themselves an arbitrary number of times without ever re-entering that password – or interacting with any authentication process. ZKX authentication sessions are transparent to the user and can be revoked at any time.
ZKX Solutions designs technologies that assume the burden of cybersecurity rather than offloading it to the user, as the industry writ-large currently does today with its “transformative” products. Instead of making it the user’s responsibility to design an “adequate” password, decide how and where to store that password, undergo regular training as to what sufficient cybersecurity practices look like, etc. – ZKX Solutions has engineered those aspects out of the end user’s purview simply with good technology. Good technology inspires good policy, which in turn cultivates good culture, leading to more success, happier users, and a more secure operating environment (which translates to more dollars to those in the audience losing profits from breaches).
The technologies we are bringing to market aim to strike the perfect balance between security and usability while alleviating the pain points caused by maladjusted technological, policy, and culture overlaps. ZKX authentication even supports MFA and strategic initiatives like migration to zero-trust networking security. Likewise, ZKX technologies minimize the traditional attack surfaces associated with all types of authentication processes, not just passwords. This makes both the end users and the host organizations more difficult and less valuable targets for would-be cyber attackers.
Conclusion
The password gets a bad rap. Sure – most of it might be warranted, but here the password is simply guilty by association. The true culprit of the weak security threshold passwords are perceived to have is the insufficient technological process that underlies traditional password-based authentication – the insecure symmetric method of the classic password. While discontinuation campaigns against the password certainly boast the right grievances, their proposed target is off the mark, as the process underlying the password makes it weak, not the password itself. Similarly, users enjoy the password in their day-to-day operations – it’s the policy: the forced regular training and burdensome password practices that the users don’t like. Good technology with simple, straightforward engineering and the courage to recycle the password into an architecture that fits the modern era is a fast track to relieving conflicts that lie in the triple overlap of policy, technology, and culture. At ZKX Solutions, our technologies do just that – and seek to make cybersecurity a responsibility left to be fulfilled by good technology and adequate policy, not a burden to be continually placed on the end user.
With that being said, we propose this alternative proclamation to be made from the ivory balcony of the ivory palace of cybersecurity down to the eager, persuadable peasants that await the death of the password:
“The password is dead; long live the password.”