A Passwordless Future: Building Towards More Secure and Usable Authentication Systems

eosio
eosio
Apr 17, 2019 · 16 min read
Image for post
Image for post

Replacing passwords with private keys in an easy to understand metaphor

The Hearsay Problem

Image for post
Image for post

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

Image for post
Image for post

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’

Passwords

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

Password Managers

Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post

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?

  • 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?

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.

Image for post
Image for post

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

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

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

“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

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


Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability. Block.one, EOSIO, EOSIO Labs, EOS, the heptahedron and associated logos are trademarks of Block.one. Other trademarks referenced herein are the property of their respective owners. Please note that the statements herein are an expression of Block.one’s vision, not a guarantee of anything, and all aspects of it are subject to change in all respects at Block.one’s sole discretion. We call these “forward looking statements”, which includes statements in this document, other than statements of historical facts, such as statements regarding EOSIO’s development, expected performance, and future features, or our business strategy, plans, prospects, developments and objectives. These statements are only predictions and reflect Block.one’s current beliefs and expectations with respect to future events; they are based on assumptions and are subject to risk, uncertainties and change at any time. We operate in a rapidly changing environment. New risks emerge from time to time. Given these risks and uncertainties, you are cautioned not to rely on these forward-looking statements. Actual results, performance or events may differ materially from what is predicted in the forward-looking statements. Some of the factors that could cause actual results, performance or events to differ materially from the forward-looking statements include, without limitation: market volatility; continued availability of capital, financing and personnel; product acceptance; the commercial success of any new products or technologies; competition; government regulation and laws; and general economic, market or business conditions. All statements are valid only as of the date of first posting and Block.one is under no obligation to, and expressly disclaims any obligation to, update or alter any statements, whether as a result of new information, subsequent events or otherwise. Nothing herein constitutes technological, financial, investment, legal or other advice, either in general or with regard to any particular situation or implementation. Please consult with experts in appropriate areas before implementing or utilizing anything contained in this document.

eosio

Published by block.one,

eosio

Written by

eosio

eosio

eosio

Published by block.one, EOS.IO is a blockchain protocol that enables horizontal scaling of decentralized applications, allowing developers to efficiently create high performance distributed applications.

eosio

Written by

eosio

eosio

eosio

Published by block.one, EOS.IO is a blockchain protocol that enables horizontal scaling of decentralized applications, allowing developers to efficiently create high performance distributed applications.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store