Every authentication system makes trade-offs between security and practicality.
TGMA aims to maximize
both characteristics by combining strong cryptographic
methods with separate communication channels.
A successful attacker must breach multiple components of the system
TGMA is intended to meet the following requirements:
Eliminate user-level passwords for authentication.
If a password is not used for authentication,
users cannot be tricked or coerced into giving up a password.
If account information stored on a server is difficult for an attacker
to successfully leverage,
the consequences of a successful attack are less likely to be catastrophic,
and the server may be a less attractive target for attackers.
Intentionally computationally- and memory-intensive password hashing
(such as bcrypt or scrypt)
are unnecessary with TGMA;
Provide a sign-on procedure that is much more secure than
one using password-based authentication;
Be acceptably quick for users to perform,
compared to entering a
"sufficiently secure" password,
and simple for them to learn to use;
Replace password-based authentication in virtually every context
where it is currently used and also be applicable in new contexts;
Be no more difficult or expensive for sites to deploy and administer
than password-based authentication methods;
Not have to rely on a vendor or central service, which may be
subject to foreign control or law;
Allow the level of security to easily be increased in response
to improvements in computation speed or weaknesses in cryptographic algorithms
without requiring any user action
(while occasional client software updates may be necessary,
no "password reset" operation needs to be done in contrast to systems
that must change their password hashing algorithm to increase security);
Accommodate optional value-added functionality, such as:
third-party sign-on approval,
rule-based access control (e.g., parental controls, user location),
and centralized functionality, including event logging, attack detection,
and disabling sign-on;
Not depend on methods that may incur unexpected usage charges
(e.g., long distance, roaming, or SMS fees);
Support the secure and private exchange of messages between
a validator and the system interface after successful M-AUTH;
Not require any mobile operating system features
beyond the basics required by the protocol specification and normal
Minimize the number of system components that have access to secrets
(such as encryption keys) during authentication;
in particular, use of a web browser as a validator is forbidden
since we consider most to be inherently untrustworthy for this purpose
because of the many well-known attack vectors and routine discovery of new
Not rely on any special-purpose hardware
(e.g., password-generating tokens, biometric scanners);
Not depend on the availability or trustworthiness of a central authority
(e.g., as might be required to validate a certificate),
be easily revocable on a per-system interface level
(e.g., a user is not identified globally, so each of a user's accounts
is independent of all his
Support accessibility features for ease of use by children
and those with certain disabilities
(therefore does not require a virtual keyboard);
strong authentication is provided without the need to remember,
record, or enter a lengthy password for each system interface;
With respect to children,
a child without access to a validator (or someone operating one for her)
cannot sign on.
It does not matter much if a child changes her normal password
(although often the old password is required to do this and a child
is unlikely to have it when the validator is used),
whereas on a normal password-based system a password change might cause
problems until the password can be reset; and
A fundamental requirement of the TGMA design is to maintain security
while assuming that an attacker:
understands the well-documented system,
knows or can easily guess valid usernames,
has access to the implementation source code, and
can freely monitor, modify, or inject network traffic.
It is assumed that best security practices are observed in
implementations and by system administrators on servers,
and that users take reasonable precautions.
The security of a given account depends on protection of the software on
a secondary computer against unauthorized access or theft.
General attacks against a server, such as
denial of service attacks (DoS),
are outside of the scope of the protocol but may be addressed by
(e.g., inserting delays between sign-on attempts,
locking out accounts after unsuccessful sign-on attempts,
using appropriate firewall rules).
A denial of service attack may prevent legitimate users from authenticating.
TGMA is not intended to supplant every authentication method in all cases.
In situations where a user has already been authenticated,
single sign-on methods can be used to provide secure sign-on with
no additional user interaction
Also, TGMA is not designed for non-interactive use cases.
When it is warranted, however, it can be be combined with other types of
authentication to improve security.
The following concepts referenced in this paper are now more
a person performing an interactive sign-on.
A user is identified by a username,
relative to a given system interface and a given server.
Each such username is associated with an account for which
various meta information is maintained,
such as information used for authentication, preferences,
identity-related information, billing information, and so on.
A username associated with a particular web site account can be
unrelated to a desktop account with the same username on the same workstation,
any interactive mechanism by which a user may authenticate himself
(as a specified username)
to a particular service accessible through a user agent,
such as a browser presenting an HTML form to sign-on
to a web-based account,
a login shell that supports command-line
or GUI-based access to an account,
the su command to switch to another user identity,
or an FTP client.
If a system interface supports concurrent authentication requests,
there can be multiple instances of the system interface
(i.e., more than one active process).
A system interface is required to have network access through which it
can directly or indirectly accept a connection from a sign-on validator.
A network-capable device that requires authentication,
such as a router,
modem, or deadbolt ("smart lock")
can be a system interface.
Authentication is successful when a system interface is satisfied that
a user can be associated with the username and account that it has asserted.
After successful authentication, a user initiates a session with the system
Mutual authentication succeeds when, in addition,
a system interface proves its identity to its user.
Although "authentication" and "sign-on" are often synonymous,
we will define them slightly differently.
Sign-on is successful if the authentication function succeeds
(i.e., the user has proved his identity to the system interface)
and all post-authentication requirements are also met.
Sign-on may fail even when authentication succeeds.
For example, if Sam provides a correct username and password he will
be authenticated by his desktop, but if he is not allowed to use his
computer after 6pm, he may not be allowed to sign on.
We do not restrict how accounts are used.
At any instant a user may be signed on to the same account multiple times
(e.g., Bob may be signed on as "bob" using two different
or different accounts
(e.g., Bob is signed on as both "bob" and
and different users may be signed on to the same account
(e.g., Bob and Alice are both signed on as "guest").
a programmable computer system that is trusted by a user and is
separate from all systems on which the user may sign-on using TGMA.
The secondary computer must be able to run the sign-on validator software
and periodically update it.
It must have network access (not necessarily continuously),
the ability to scan a barcode, or both.
It is assumed that access to the secondary computer requires authentication
and appropriate security measures are observed.
The secondary computer's method of communication with the system interface
should be independent of the communication path between the user agent and the
making it necessary for some kinds of attack to
infiltrate two separate networks simultaneously.
a server provides one or more services,
each of which requires user authentication and is accessed via a
A system interface may be physically attached to the server
(e.g., the console device) or provided over a public or private network.
A service provider can be a server or system interface,
or a business or organization that offers services to users.
a person or software that attempts to gain unauthorized access to a system
by circumventing security measures or taking advantage of a design
or implementation deficiency in violation of the system's policies
or terms of service, or applicable law.
A system is considered to be compromised and untrustworthy
if it is possible that an attacker has been able to copy information
from it or modify it in any way.
a dynamic group of hosts or services that coordinate information
sharing through administrative and business practices.
The hosts may share a common domain name suffix, but need not.
Sign-on validator or validator:
a tool to help a user authenticate and manage security-related information.
A validator is secure software, running on a secondary computer or special
device, that acts on behalf of the user or a delegated third party to
1) validate the identity of the system interface with which a user is
interacting and to 2) prove the identity of the user to the system interface.
A sign-on validator can manage one or more accounts (system interfaces)
for a user.
A user may have multiple instances of his validator,
each on a different secondary computer
(e.g., one copy on a phone, another on a tablet,
and a third on a laptop).
Instances of a user's validator can share configuration information,
although each instance is uniquely identified
(e.g., using the device's hardware serial number,
an SSL client certificate,
or some combination).
It is assumed that access to the validator requires separate authentication
using a password,
thumb print, etc.
Appropriate practices to maintain security are assumed,
such as having an inactivity timeout and maintaining all
authentication-related data in a
It is assumed that, in general, although a validator can initiate a
network session with an arbitrary server,
it is not possible for it to accept incoming network connections.
any available information related to a particular instance of authentication,
such as the time and date, IP addresses, the username and server's hostname,
type of service, secret keys or values obtained from them,
software versions, applicable rules and configuration, etc.
Sign-on approver or approver:
The sign-on approver is a tool to help a third party monitor
and override authentication.
Immediately after authentication and prior to termination of the sign-on
the system interface can invoke an optional, client-specified callback
(via a URL) that is passed authentication context.
The callback may unilaterally
a network connection over which a system interface and validator
This will typically be a TCP/IP connection over the Internet/LAN and Wi-Fi,
but alternative networking configurations that can provide reliable,
flow-controlled, bidirectional data transmission are possible (Bluetooth).
Communication is not assumed to be private or tamper-proof.
A network connection may pass through a firewall, proxy server, or other
A TGMA system comprises the following active components:
A server provides one or more services.
A user interacts with a service through a system interface.
Communication between active components may be carried out over
public or private networks, using cell phone or
Wi-Fi TCP/IP service.
Communication from validators to a given server must be demultiplexed from
a single reserved port to a particular instance of authentication.
data from a validator to a given server may arrive over
an external network (e.g., a cellular data network).
It may therefore be necessary to accept Internet traffic from a validator
on a firewall/DMZ server and relay it to the internal server where
the user's instance of authentication
Communication need not be connection-oriented (TCP/IP).
In some contexts, UDP may be preferable to TCP/IP.
Each authentication instance at a given server is uniquely identified
by a tuple, for instance:
The tgma-account-name is the name of the owner of the account
on this server.
A passcode, described below,
is used to match a validator's connection to the corresponding
an interface-identifier, assigned by the system interface and
associated with the sign-on instance may be included,
such as a device name (e.g., tty17),
client socket address (10.0.0.130:28717),
or memory address (&usertab).
The name may be local to the system interface and therefore
difficult for a user to determine.
The authentication component interacts with the system interface and
account information on the server to verify the identity of a user.
Like the file or database used to maintain user account and password
access to the private elements of the TGMA account information
must be carefully administered.
The validator is software that runs on a device separate from the
It interacts with the user and the system interface to verify the user's
identity with the system interface and confirm the identity of the system
interface to the user.
It is possible to create a custom validator that includes
(or, equivalently, a custom application that includes validator functionality).
Optionally, after successful authentication but before sign-on,
the sign-on approver component interacts with the system interface to
perform custom actions, which may be
on behalf of a third-party.
For the vast majority of users,
the requirement for a different secure password for each account
means that either passwords must be written on paper and searched
for when needed,
or password management software used.
Entering a secure password, for most people,
will always be slower and more error prone than typing a weak password
The idea of moving much of the validator's functionality to
a secure system managed by or on behalf of the user may be appealing.
By adding a level of indirection to the architecture,
the validator would mutually authenticate with the secure system,
and the secure system would perform authentication with a system interface.
This would offer some advantages,
most importantly to enable a managed authentication service,
but it would introduce additional moving parts and complexity.
It is useful for development and testing, however,
since it allows a browser-based GUI that approximates a validator interface
to be rapidly developed.
An HTML menu or even individual links (bookmarks) can be used to trigger a
particular validation operation,
with the actual validation logic being executed elsewhere.
If only for development and testing purposes,
the system interface's side of the protocol can be run as a separate server
rather than calling the TGMA library code directly.
For instance, a PAM authentication module can make an HTTP request
to a CGI program that implements TGMA server functionality
(such as dacs_auth_tgma).
The system interface blocks until the protocol completes, the CGI program
indicates the outcome, and the system interface resumes.
This makes it easy for any system interface capable of making an HTTP request
to work with TGMA.
It is common and expected practice for users to
password-protect general access to their mobile devices (or use a
biometric method) and to similarly control access to their important mobile
device apps, such as banking or email apps.
Apart from their use as a sign-on validator or password manager,
because of the value of cell phones and tablets, and the personal and
financial information they typically contain, these devices will always be
attractive targets for theft.
Possible methods of strengthening the protocol or validator implementation
are being investigated that would make it even more difficult to use a
stolen validator or obtain useful information from it.
Notably, the repercussions from copying another person's password,
by whatever means, are likely to be much less severe than those from stealing
that person's mobile device.
This might also be invoked upon unsuccessful authentication for
This capability could be present in just about any authentication system.
While it is not a core feature of TGMA, because it is particularly
useful for TGMA it is a documented component in the initial design.
We are going to say that attacks against TGMA
are "difficult" rather than "impossible" because there is always
the possibility of an implementation, configuration, or hardware error,
a new weakness in a cryptographic method,
a previously unknown kind of attack,
and so on.
There is a theoretical possibility of successful attack
on nearly every system.
careful use of cryptographic digests,
keyed-hash message authentication codes,
cryptographic ciphers, key-agreement protocols, and so on
with large key sizes are capable of making many attacks infeasible
and reducing the number of attack vectors.
Consider the common case where a student wants to sign on to a workstation
in a classroom.
After entering her username,
she her validator must be able to communicate with the workstation.
If she does not have Wi-Fi access to the workstation,
her validator must use her cellular service to establish a connection
Since the workstation is not directly reachable from the Internet but is
instead on a private intranet, and behind a firewall,
software must be in place to accept the connection and relay it to her
workstation over the intranet.