This document describes the design and architecture of a general-purpose authentication system that is superior in many respects to password-based authentication methods, two-factor authentication methods, and password managers. The architecture ensures that information useful to attackers is always held within the system's most secure components, eliminating many of the attacks that plague password-based authentication, helping to protect information stored in user accounts, and preventing unauthorized system access.

Central to the architecture is the use of a secondary computer called a validator that is responsible for managing account information on behalf of a user and executing the system's secure cryptographic protocols. Beyond its application to user authentication, a validator can act as a general purpose personal security assistant.

Functioning prototype components have been implemented and can be demonstrated.

This document provides a higher-level description of the system, omitting many technical details. Although specifics of the mutual authentication protocol are not presented, the system is largely composed of documented, standardized, and well-analyzed algorithms and protocols. Some related technologies are described and critiqued, but not exhaustively. Basic knowledge of client/server architectures, computer security, and cryptography is assumed.

Password-based authentication methods have many serious security weaknesses, administrative problems, and usability issues. High-profile attacks aimed at client software, server software, and users themselves via social engineering have leaked private information, resulted in identity theft, damaged or misused systems or property, and so on. Efforts to find a suitable replacement approach have been largely unsuccessful.

We propose a replacement for password-based authentication that addresses many of its weaknesses and offers additional features. It might be approximately described as a combination of password-management software and multi-factor authentication. Its novelty rests on:

• Eliminating password entry or recording by users;
• Using an independent, mobile device as a cryptographic assistant at sign-on time;
• Using strong, tunable, and well-known cryptographic methods;
• Combining authentication components in such a way that, despite the possibility of attacks on client software, network communication, or server account information, user accounts cannot be compromised.

While the architecture has wide application, it is presently felt that the best avenues center around improving security or accessibility to software, products, or devices that would ordinarily be password protected and where security breaches may have significant financial, legal, or safety consequences.

The primary goal of this work is to develop a more secure and versatile alternative to username/password authentication for niche and/or general-purpose applications.

A secondary goal is to develop a cryptographic assistant for managing user authentication and for integration with any software that requires secure client/server and/or peer-to-peer communication, as a better alternative to username/password authentication and SSL/TLS communication.

Claims
The design is based on the following assertions, which will be justified throughout this document:

• Average users today interact, directly and indirectly, primarily with computer systems and applications through the web. For this they mainly use one of the popular off-the-shelf web browsers (whether because of personal preference, availability, or requirement) and TCP/IP over the Internet or an intranet. Many kinds of web interactions require user authentication.
• Desk top and laptop computers are commonly used, despite inroads made by mobile devices.
• Users also run special-purpose, web-based apps on mobile devices to access specific content (e.g., banking apps, shopping apps, and so on). These apps are effectively custom browsers.
• Authentication through popular web browsers, and many special-purpose apps, is fundamentally insecure. This is not to say that this is necessarily always the case, but web browsers have become very large and complicated pieces of software and if there are any vulnerabilities, attackers will find ways to exploit them.^[7] Likewise, web servers and related components are subject to bugs and misconfiguration, and have been the targets of a wide variety of attacks. Users of mobile devices assume, sometimes incorrectly, that their Internet connectivity is secure.
• There is a recognized need for an authentication method that is better than password-based authentication, especially in web-based contexts.
• Users will balk at using software that employs an authentication method that is inconvenient or difficult to use, or merely perceived to be so, compared to the password-based method to which they are accustomed.

It is intended for the architecture to be open, using standardized (or de facto standard) cryptographic methods, and a reference implementation made available.

Time-Gated Mutual Authentication (TGMA)^[1] is a software architecture for performing convenient, highly-secure mutual authentication (M-AUTH) between a user and a service provider by employing a secondary computer. A service provider is any software that requires its user to identify herself through a suitable system interface. The service provider can be a computer system (desk top, laptop, workstation, display manager, screen saver, etc.), web site, command, device, and so on. The secondary computer is intended to be a programmable personal mobile device, such as an Internet-capable cell phone (a "smart phone") or tablet, but it could also be a laptop, special-purpose device, or even a general-purpose computer system. The secondary computer is configured with user account information as required and runs software that conducts the TGMA protocol with server-side components.

By moving certain data, functionality, and protocol from the application software that needs to perform authentication to the validator, many avenues of attack based on compromising the client disappear. In effect, the user authenticates a transaction rather than himself. We will generally frame the typical transaction as signing on through a system interface, such as a login screen, but that is not the only possibility.

Personal mobile devices have become small, commonplace, relatively inexpensive, and powerful. As they are increasingly used for a wide variety of everyday tasks (financial, informational, entertainment, administrative, and more), they have become indispensable. Mobile devices are typically equipped with at least one data transmission method, non-volatile memory, one or more access control mechanisms,^[2] and a camera. This makes them particularly well-suited to this application. As the cost of hardware components decreases, affordable special-purpose devices become more attractive, but there will always be a desire to combine frequently-accessed functions into a single device (e.g., the tricorder).

The architecture provides important security benefits both to users and service providers compared to password-based authentication ("username/password"). In brief, for users:

• Strong authentication is provided without users having to remember or record (and safeguard) a password for each account. An average user can easily amass from tens to hundreds of password-protected accounts over time (conservative averages of 26 and 40 online accounts have been reported). The need to change passwords is greatly reduced, but if required, can be automated.
• User accounts are safer because many kinds of attacks are either prevented or rendered impractical. This makes Identity theft much more difficult.

For service providers:

• User authentication is always more secure than a conventional password-based method, and because weak passwords and insecure authentication algorithms are eliminated, equally strong for all users.
• More of the responsibility for security is shifted to the user, his device, and secure authentication software that runs on the device. It is very difficult for an attacker to take advantage of account information stolen from a server.

An important design goal is to minimize inconvenience for authenticating users and system administrators compared to password-based authentication. Though not a drop-in replacement, adoption of the new system on the server side should be straightforward for system administrators.

The system architecture lends itself to several powerful features. Sign-on approval lets a user or a third-party track sign-on requests in real time. Rules can be evaluated to decide whether an authenticated user should be allowed to sign-on.

For authentication purposes, the TGMA protocol does not need to run on top of SSL/TLS, although it can, perhaps to provide secure communication after mutual authentication or for practical reasons. In some cases, light-weight, very secure end-to-end communication is possible without the many weaknesses related to SSL/TLS (RFC 7568: SSLv3 Is Comprehensively Broken, sslstrip), and without the need of SSL/TLS certificates and certificate validation.^[3] The authentication protocol is entirely peer-to-peer, without the participation of a third-party server.

Here are a few applications of the architecture:

• Allowing any user with an account configured on his mobile device to sign on to a workstation, screensaver, or web site without entering a password.
• Allowing a parent to sign a child on to a workstation without giving the child her password or having to type it for her.
• Allowing a teacher to sign students on to workstations or class web sites without providing them with passwords.^[4]
• Allowing a user to give a friend or sysadmin (temporary) access to an account in order to get assistance (without revealing a password^[5]).
• Granting web-based access to a protected document (URL).
• Allowing a user to decrypt a document without having to give the user a copy of the key.
• Monitoring and logging all sign ons as they happen.
• Disallowing sign ons by specifying rules.

TGMA can be deployed as a two-factor authentication method. Successful authentication can require a particular device (something the user possesses) and information associated with the user's account (secrets the user knows). On the device, a password can optionally augment an account (another secret the user knows).

More detail is presented in Benefits and Advantages.

Computer systems must make trade-offs between security and practicality. If security is maximized, a system will be far too inconvenient for everyday use, and will therefore have limited applicability. If usability characteristics, such as cost and functionality, are of prime importance, a system must relax security constraints. Additionally, it should be recognized that not all systems demand the same level of security. A user's home desk top system probably does not need as strong an authentication method as that user's banking web site. It is necessary to find a suitable balance between security and usability. Unfortunately, users have demonstrated a strong preference for ease of use.^[6]

For many use cases, the authentication system described here is intended to be a better alternative to password-based authentication methods, many two-factor authentication methods, and password managers, in most contexts, over public and shared computer networks. Security is greatly improved without sacrificing overall ease of use.

Continued in Part 2.