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.
In particular, the specifics of the mutual authentication protocol
are not disclosed.
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
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
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
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 perceived to be inconvenient or difficult to use 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.
Introduction to TGMA
Time-Gated Mutual Authentication
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
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,
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
In brief, for users:
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
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.
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
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,
and without the need of
SSL/TLS certificates and
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
Allowing a user to give a friend or sysadmin (temporary) access
to an account in order to get assistance
(without revealing a password).
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).
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.
it should be recognized that not all systems demand the same level
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.
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.
The name "Time-Gated Mutual Authentication",
may yet be changed to something more catchy.
Access to a personal device is typically protected by a variety of methods,
such as a password, fingerprint, inactivity timeout, or a
remote reset feature.
Frequently quoted studies:
a) approx. 60% of all SSL server certificates are invalid and
b) an invalid SSL certificate has no effect on people visiting the web site.
In some situations,
such as administering classroom or lab facilities, a laptop may be a
preferable secondary computer.
Sometimes a sysadmin cannot use an administrative password
and must obtain a user's password.
It turns out that users commonly use the same password for multiple accounts
and so might have legitimate concerns about sharing it.
Or, a user might have chosen a potentially embarrassing password.
By "ease of use", we mean the actual or perceived
convenience, usability, speed, and availability of a method
for a wide class of users.
Interface "friendliness" characteristics,
such as functioning in much the same way across different kinds of devices,
are also relevant.