A Passwordless Future: Building Towards More Secure and Usable Authentication Systems
Replacing passwords with private keys in an easy to understand metaphor
With the introduction of the EOSIO Labs™ initiative, we have begun innovating in the open with regards to the future of blockchain technologies built on EOSIO. Our first release under this initiative explores the future of private key management and its implications on security and key management — the Universal Authenticator Library (UAL). What underlies the philosophy of this release is an exploration into a larger problem, one that is centered on how passwords and authentication have been implemented across the internet, blockchain or otherwise. While there is no software release accompanying this post, this article aims to discuss problems that plague existing authentication systems, and the modern attempts to move beyond passwords attendant to such problems. We will then propose, in abstract, a new model using the metaphor of a “pass”, such as an airline ticket or a library card, to address these problems in a secure and usable way.
The Hearsay Problem
Current methods of authenticating users suffer from what we will call “The Hearsay Problem”. Hearsay is any information received from one party about the statements or actions of a second party that cannot be adequately substantiated. Our stance is that all information sourced from systems which rely on current state-of-the-art methods of authenticating users would qualify as mere hearsay if any of the involved parties were to call the validity of the information into question.
To illustrate, imagine a poorly received social media post allegedly authored by a well-known politician that threatens to destroy said politician’s career. How do we know for sure that the politician did, in fact, author the damning post? While the author could indeed have been the politician in question, it could equally be anyone with access to the politician’s social media account. To extend this reasoning, the pool of possible ‘authors’ could include any number of people close to the politician, or adversarial hackers in a targeted attack. Yet no one, including the politician and the social media service provider, would be able to present conclusive, non-circumstantial evidence that the politician was or was not definitively the author of the post in question.
To use legal and technical terminology, this characteristic is referred to as repudiability, and it is not a desired trait. Two primary factors lead to this characteristic of repudiability in our social media example above; the first factor is an authentication scheme that requires disclosure of a secret in order to validate the possession of that secret. In security schemes (like passwords) that are subject to this factor, it is impossible to create logs of user activity that are verifiable by anyone other than the party and the counterparty. The second factor is the lack of means to prove that the data within a system that actually represents the intent of the user, which leads us to another problem we are calling, “The Blank Check”.
The Blank Check Problem
The Blank Check problem is present in any system that can take action on behalf of the user without needing the user’s explicit consent on that specific action. It is also present if the means of capturing the user’s consent is anything short of a log of proof that the user was informed of the implications of every individual action and explicitly consented to each action.
In the example above, this problem adds the social media service itself as well as many of its employees to the list of parties that could have posted the damning post. How can we prove that the social media service or one of its employees did not have compromising access to “post” on behalf of the politician? A higher-stakes example of this problem that showcases the appropriateness for the name “The Blank Check Problem” is that of a bank account. Technologically speaking, there is nothing to prevent your bank from liquidating or locking your funds, and there would be no means of proving any wrong-doing, as the Bank could fabricate records of seemingly legitimate transactions. This would no doubt pose grave consequences that affect many stakeholders in a material way.
The ‘Two Become One’
An astute observer might have noticed that these problems are really two outcomes of the same underlying problem: the lack of provable audit logs. While there are technologies that do address this fundamental shortcoming in our current systems, like certificate-based systems based on asymmetric cryptography, they have yet to achieve a level of user-friendliness that makes them accessible to the general public. By addressing this challenge with easy-to-understand metaphors for a theoretical solution we will present below, we have the opportunity to improve the security and usability of all of our systems, for every kind of user, and improve users’ experience in the process.
Passwords
When discussing cybersecurity, two basic terms should be defined: ‘authentication’, which is the process by which a user proves that they are who they say they are by possession of particular identifying credentials, typically with a username and password; and ‘authorization’, which is the process by which a user’s actions within a software platform are allowed or restricted according to their identity.
Since the 1960s, passwords have been the de facto method that allows a user to authenticate themselves to a device or service. Password authentication is, by now, a well-understood technology for engineers. For users, passwords have become a simple concept to grasp; they are comfortable and familiar even for non-technical users. But while their simplicity and familiarity are a strength, passwords suffer from many weaknesses as well.
Such weaknesses are both technological and human in nature. Some of them have been widely discussed, including in exhaustive detail in the NIST Digital Identity Guidelines, so we will be not be repeating them here. What is important to remember, however, is that passwords do not enable trustworthy auditable logs of the actions that a user has authorized. To authenticate with a password, it must be revealed, and in order to check the validity of a user’s password, service providers must have stored them in some form of centralized infrastructure. This means that no one but the service provider can have confidence that any audit logs they keep are accurate representations of a user’s actions. For this reason, systems that rely on passwords for authentication are subject to both The Hearsay Problem and The Blank Check Problem as described above.
Modern attempts to improve or replace passwords
There have been several attempts over the years to incrementally improve or replace passwords. Below we will review a few of the most successful cases along with their strengths and weaknesses.
Password Managers
The existence of Password Managers represents an admission of several of the fundamental flaws of passwords. They attempt to improve the situation by freeing the user from having to generate and remember sufficiently complex passwords, thus allowing for single purpose passwords that meet a much higher level of security rigor.
Used correctly, Password Managers do improve security, and to a limited extent, the usability of systems with password-based authentication. Yet anyone who has tried to teach their parents, children, or non-technical friends to use today’s iterations of password manager software is painfully aware that they are neither widely adopted nor usable enough to become so.
From a technical perspective, there are no standards for password managers. They attempt to guess when a user is creating an account, logging in, or updating their password to be more convenient, but they often fail. They provide the basis for an improved solution, but ultimately, they are still just passwords and are still subject to both The Hearsay Problem and The Blank Check Problem.
Two Factor Authentication
In recognition of the weakness of passwords, attempts have been made to layer on additional security to ensure that the password itself is not the single point of failure. This approach is usually called a second factor, or two-factor authentication (2FA). There are a variety of implementations of 2FA, and while all of them do add differing degrees of incremental security to password-based authentication systems, they make up for it with added complexity in terms of setup and end-user operation. A common 2FA solution relies on SMS messages to provide time-based one-time passwords (OTP). Much like passwords themselves, two-factor solutions suffer from the problem that they are not auditable and are vulnerable to the security practices of phone carriers which deliver SMS messages to your device.
This lack of provable auditability means that 2FA still does not solve The Hearsay Problem or The Blank Check Problem.
The WebAuthn Standard
WebAuthn is a new authentication standard proposed by The World Wide Web Consortium (W3C), an international community of member organizations, a full-time staff, and the public work together to develop Web standards. WebAuthn comes very close to solving all of these problems for Web-based transactions by using asymmetric cryptography, instead of passwords, providing one of the necessary ingredients for overcoming the problems we have outlined. However, in order to prevent users who lose their devices from being locked out of every service, WebAuthn is designed to be used in conjunction with passwords, rather than as a replacement.
Another significant important limitation of WebAuthn is that it was designed as a proof of presence, not as a proof of consent. It is not defined to allow per-transaction authorization requests that are auditable by peers. So once again, systems that rely on WebAuthn don’t have provable audit logs and are subject to both The Hearsay Problem and The Blank Check problem.
Blockchain as a Potential Solution
Blockchains have popularized the idea of authenticating the user for every action they authorize, using public key cryptographic signing of transactions to accomplish this goal. This is a big improvement on passwords and a step beyond what WebAuthn can provide. It also satisfies the first factor necessary to address The Hearsay Problem: provable auditability.
Unfortunately, today’s blockchain user interfaces also do not define a standard for describing authorization requests in a human-friendly way to users so that they can be displayed in a trustworthy context for user approval. Without this human-friendly request rendering standard, users cannot know what they are agreeing to. This means that even though blockchains create a provable auditable log, they lack the means to prove that the data within a system actually represents the intent of the user. Thus, they are still subject to the Hearsay and Blank Check problems.
Back to our social media example, if a social media platform was built on a blockchain, they would be able to prove that the politician in question did, in fact, sign the action that resulted in the post, but they would be unable to prove that they (or another party) didn’t trick the politician into signing the action by misrepresenting it.
A Theoretical Solution: “Passes” instead of Keys or Passwords
To advance the security of our systems, we need proof of user consent, combined with a level of simplicity and usability that exceeds even passwords. This means we must communicate complex technologies like asymmetric cryptography through a metaphor that is immediately understandable for every kind of user, not just technologists. One concept that meets these criteria is that of a “pass”. In describing the concept of a pass, we will show how this theoretical solution of a pass used in a Pass Manager Application can satisfy both The Hearsay Problem and The Blank Check Problem we have outlined.
For users, a pass represents a familiar and tangible means of proving possession of a credential. Every day we interact with physical passes as part of our daily routines. As a library user, you simply show up and present your library card. As an airline passenger, you simply show up and present your ticket. These are examples of single-purpose passes, for services that do not provide a single-purpose pass, you might present your Driver’s License to prove your identity.
To support authentication and authorization use cases, we introduce the concept of the digital “Pass Manager”. A Pass Manager is a passwordless paradigm for registration, authentication, and authorization use cases.
What could you do with a Pass Manager?
Issuance and Revocation
- Service Providers could request the Pass Manager to issue a new pass for a user.
- Users could organize their passes into groups. (e.g. my work passes, and my personal passes)
- Users could authorize and deauthorize passes across multiple devices.
Authentication
- Service Providers could request proof of a user’s possession of a pass.
- Users could provide proof of their possession of a pass.
Authorization
- Service Providers could request proof of a user’s authorization to perform a particular action, on the authority of a pass the user possesses.
- Users could see authorization requests rendered clearly in a human-friendly way, and choose whether to authorize the action, on the authority of a pass they possess.
How would a Pass Manager work?
A Pass Manager implements a (yet-to-be-defined) standardized protocol for issuance and revocation of passes, authentication, and authorization with passes. A Pass is a conceptual abstraction that encapsulates credential info (keys).
The experience of using a digital Pass Manager should be very similar to the physical analog of pass cards. The user simply arrives at a service (whether it is a web app, a native app, a point of sale system, or a kiosk), and presents a pass to sign in or authorize an action. This is like a college student using their College ID to gain admission to a collegiate sports event, then once inside, using it to buy food at a stand with their campus dining balance, being presented with order confirmations before committing to the transactions.
Under the hood, a blend of technologies can work in tandem to produce superior security and usability for users, including cryptographic signing, hardware keys, and biometrics for credential security, as well as a transport-agnostic protocol for portability.
Anytime a user’s consent is sought by a Pass Manager, human-friendly descriptions of the action should be shown to the user, and that description (or a cryptographically verifiable derivative of it) should be included in the signed response from the Pass Manager. The use of keys means that logs are non-repudiable and can be verified by third parties, and the inclusion of the human-friendly description in the signed response can serve as proof of the user’s intent. These characteristics solve both the Hearsay and Blank Check problems.
This model can support both current web technology and future blockchain technology use cases. It is also capable of providing a clear user experience for both login and authorization use cases.
What is necessary to make Pass Managers successful?
Interoperability
First and foremost, a Pass Manager protocol should be built to allow users the freedom to choose a Pass Manager that best suits their needs. This is important because it prevents vendor lock-in, creating the free market that is necessary to foster innovation in both security and user experience. This way, the best user experience with acceptable security will win.
To provide this freedom of choice, there will need to be standard protocols for signup, login, and authorization. Authorization, in particular, is an interesting challenge, because it requires the definition of a standard for describing requests for authorization to users in a way that is understandable, auditable, provable, and portable.
Portability
Secondly, the Pass Manager protocol should be built for portability; meaning: 1) support for every kind of application or service running on any platform, 2) support for limited or no network connectivity, 3) support for multiple devices, and 4) support for cross-device communication.
Users have desktop computers, laptop computers, phones, tablets, smart watches, and USB keys. So a simple and seamless experience for issuing and revoking pass access across multiple devices is critical. Users also interact with point of sale systems, untrusted public computers, vending machines, and kiosks. So the ability to interact from one device to another, with or without network connectivity, without needing the devices to trust each other is necessary.
These requirements can be met by defining the Pass Manager protocol to be transport agnostic. This means that the protocol should focus on defining the nouns and verbs that implementing systems must be able to fluently speak, and allow the transports through which they are spoken to vary. Examples of transports might include custom protocol URLs, Apple Universal Links, Android Intents, server requests, QR codes, Bluetooth, NFC, and JavaScript APIs. With this flexibility, Pass Managers can be truly portable.
Usability
Users should not have to consider the implications of whether they are using a web service with a database backend or a blockchain system. In the case of blockchain, they should not have to know what blockchain platform or network the application they are using is built on. They should only need to consider their use case. Things like…
“I’m withdrawing funds from an ATM.”
“I’m logging into my email.”
“I’m liking a post on social media.”
“I’m buying chips from a vending machine.”
“I’m transferring 100 tokens from Dan to Brian.”
Never things like…
“I’m signing a transaction, with an R1 key, authorized for my blockchain11 account, on the example.com dapp, which is built on the Telos blockchain, which is built on the EOSIO platform.”
Safety
Current implementations of both passwords and public key systems are unsafe for a variety of reasons. Pass Managers must do better.
In order to protect users from attacks on centralized honeypots of credentials, secret credential data should never be stored on centralized infrastructure in any form (hashing and salting is not good enough). In order to protect users from having their credentials stolen through phishing, malware, and man-in-the-middle attacks, users should never actually know what their credentials are, and they should never be entered manually or automatically into any service. In order to protect users from being tricked into adding malicious passes, users should not be able to add or remove passes themselves. Instead, a trusted Pass Manager should handle this automatically on behalf of the user in response to the user visiting new services or getting new devices.
The Future is Wide Open for Pass Managers
In this article, we have laid out problems to be solved to address security and usability concerns with current state-of-the-art methods for securing user accounts. We have presented the concept of Passes replacing passwords and the digital Pass Manager as a means of solving these problems. We have discussed the necessary attributes for a Pass Manager protocol to succeed, but we have not explicitly defined the protocol. We encourage enterprising developers to solve the problems that plague both password and key-based security systems and to consider the Pass metaphor as one way to accomplish that goal.
All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
Important Note: All material is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations, and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.