The Password Is Dead; Long Live the Password

From IC Insider ZKX Solutions

Author: CTO Collin Sweeney

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 has 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 connecting link 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”) the 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 engaging 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 is the highly familiar process that has been driving the execution of privileged network action since the days of ARPANET.

If you haven’t been living under a rock since the Bush administration, you most likely either 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 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: 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.

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 (one of the three fundamental pillars of good cybersecurity) 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 the password technology, certain password policies were introduced that dictated things like password length, inclusion of special characters (e.g., ! ? #), inclusion of capital letters, inclusion of numbers, and 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?

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 login 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, which leads to more success, happier users, and a more secure operating environment (which translates to more dollars to those of you 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 overlaps in technology, policy, and culture. 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; making both end users and host organizations more difficult and less valuable targets for would-be cyber attackers.

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 it is the process underlying the password that 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.”

About ZKX Solutions

ZKX Solutions is a U.S.-based technology company that has developed new patent-pending authentication software built on a foundation of Zero Knowledge Proofs. Our software is an iterative, trust-building platform designed to bring next-gen multi-factor authentication (MFA) to networks of any kind, from tactical DIL environments to zero-trust, cloud-based enterprises.