Prototype components have been developed as a proof of concept.
Account information is built-in to the prototype software,
for expedience, but a M-AUTH protocol is actually
conducted over a network between two physically distinct computers,
or between a computer and a mobile device.
The prototype system can be demonstrated using:
A portable, command-line validator (client) that fully implements the
It produces QR codes that can be scanned by any of several free apps.
[Recall that these QR codes represent a passcode only.
They do not encode a URL, or include a password or any other
While it does not run as an app on a device,
such as a cell phone or tablet, the command-line implementation was
written quickly and much of the code it uses has been written as a library.
Account information is built-in to the validator but can easily
A PAM authentication module
running on any supported Unix-type system to provide a
system interface for many PAM-capable system services,
ssh,login, and su).
Both the module and the command-line validator
can be demonstrated on FreeBSD 10.1, CentOS Linux 6.7, and Mac OS X 10.11.
Despite the fairly primitive API provided to modules to ask the application to
printing a QR code on a plain text interface is possible.
PAM can be configured to try TGMA first and fall back to another
authentication method when necessary.
Important: to avoid locking yourself out of your system,
ensure you have at least one other existing sign-on before
modifying the PAM configuration for login.
A web-based authentication service to demonstrate TGMA sign-on
with a non-PAM based type of system interface.
A server-side component displays a passcode and waits for the user's
validator to connect and complete the M-AUTH protocol.
Purely for demonstration purposes and ease of implementation,
a web-based validator that uses a basic browser as a user agent
and a CGI component to provide validator functionality.
A dynamically generated web page presents the user with a menu of
known system interfaces from which one may be selected and allows
a passcode and optional password to be entered.
Essentially, this is the command-line validator inside a CGI wrapper.
Any system capable of running an Internet-accessible web service
(e.g., a simple CGI program)
can be used to demonstrate a sign-on approver web service; and
The prototype is portable and runs on FreeBSD 10, CentOS Linux 6.7,
and Mac OS X 10.11.
Open-source licensed software is used for supporting libraries
(encryption, QR code generation, CGI).
Portions of the web-based sign-on demo use the
DACS support library and
some cryptographic functions from
OpenSSL are used.
A communication demultiplexing server has not yet been implemented,
but a single-threaded implementation using non-blocking I/O
could easily be written:
Poll for an incoming connection on the well-known port.
Accept the connection, read and validate an
message (from a system interface) or
(from a validator):
If AuthRequest, queue the request.
reject if a matching AuthRequest
is not queued, otherwise initialize an authentication
transaction for the connection pair.
Asynchronously and bidirectionally, forward data between a
transaction's connection pairs until either side closes the connection.
Check for timeouts, deleting any queued requests that are too old and
terminating any transactions that appear to have stalled.
Go to Step 1.
Care must be taken to ensure that no information is communicated that could
benefit an attacker.
Currently, the prototype uses a
connection between the validator and system interface.
Whether communication based on
is a better choice will be investigated.
The amount of information stored in the validator and on the server
will vary, depending on the exact configuration, but should not exceed 2KB
per user account at the highest security level.
On the server, this is information is in addition to the usual system
One user account entry could apply to more than one system interface
(e.g., the login and screensaver system interfaces could be associated
with the same server-side TGMA account record).
Any suitable mechanism can be used to store this account information
provided its access is appropriately restricted.
PAM Authentication Modules and Standard System Services
Most Unix-type systems support the
Pluggable Authentication Module (PAM)
although the system services that use PAM vary on different platforms.
The two main implementations are
(for BSD-family systems, Mac OS X, and as an option on some Linux systems) and
(for Linux-family systems).
Different implementations of PAM may incorporate extensions and minor changes.
It does not appear that Microsoft Windows platforms
Rules for how each PAM-enabled system service uses PAM
are typically found in the /etc/pam.d directory.
Depending on the operating system,
PAM modules are usually found in
/usr/lib or /usr/lib64,
/lib/security or /lib64/security
as dynamically linked shared libraries.
Unfortunately, not all system services fully implement PAM support,
or they combine PAM support with application-specific prompting because
PAM is not sufficiently versatile.
the PAM API does not supply a mechanism for displaying a bitmap image,
as might be needed by a display locking application.
The FreeBSD FTP daemon
uses PAM but does not fully implement a conversation function.
this may be done via
This means that it is not possible for the TGMA PAM authentication module
to ask ftpd to display a passcode to the
user without modifying ftpd.
(from a shell window as /bin/login)
provides the necessary functionality but CentOS does not.
On CentOS Linux (6.7) and FreeBSD (10.1),
the su command provides the necessary PAM support.
With respect to customizing login prompts,
PAM provides an API for authentication modules to set the program's
username prompt, but not all programs that use PAM honour this setting.
It is not yet known which other system services can provide
complete PAM support without
Support for TGMA from a Mac OS X login or screensaver window
has been partially implemented without having to modify standard
A rough version has also been demonstrated with the
X display locker using its PAM support.
Some minor customizations to its user interaction were required.
It is not yet known what would be required to support sign on
from an X11 display manager
but it is likely that the standard (open source) software will
need to be modified similarly.
a system administrator must ensure that the port used by the
validator and system interface has been configured appropriately
for them to communicate.
There can conceivably be more than one sign-on interaction
in progress on the same system interface and even for the same account.
Authentication via the PAM authentication module must therefore either be
(i.e., one user at a time, per system interface or per system)
or use a more sophisticated implementation to accept concurrent validator
connections and direct each one to the appropriate module instance that is
awaiting a validator.
The straightforward solution is to run a per-system, proxying-type
(demultiplexing) service that accepts incoming connections both
from validators and individual PAM authentication module instances
(or uses system IPC for the latter)
and forwards data traffic for each authentication session.
Carrying this a step further,
the demultiplexing service could be run on a firewall to allow
validators connecting from external networks to communicate with
intranet system interfaces.
Because web-based sign-on can be implemented in many ways,
and the resulting credentials can be sent from a web browser to a web server
in various ways,
such as through an HTTP cookie, in an Authorization
or other HTTP header, or encapsulated within a URL,
a general approach used in the prototype implementation
(dacs_auth_tgma) will be outlined.
The user visits a TGMA sign-on web page
where he is prompted for a username.
The user specifies a username and submits the HTML FORM
embedded in the web page.
This invokes an authentication component on the server,
passing the username as a parameter, and starts the authentication timer.
The authentication component is functionally similar to the
PAM authentication module and shares much of the same code base.
A new web page is returned to the user's browser that
displays a passcode (e.g., as a QR code).
The passcode may be embedded as a "hidden"
an HTML FORM on the web page or appear as a URL parameter.
State parameters, as well as the username and possibly a protective message
authentication digest, may be included.
The server-side authentication component waits for a connection from the
user's validator, up to a configured maximum length of time.
The user interacts with his validator in the usual way,
entering the passcode or scanning the QR code
(recall that it is currently being displayed by the web browser).
The validator connects to the authentication component and
completes the M-AUTH protocol.
Sign-on completes and the user's browser is automatically
redirected to a new web page.
If the validator allows sign-on to proceed
(and, optionally, the approver as well),
and the authentication component is satisfied with the result,
credentials will be returned.
If sign-on fails, the user is notified and his browser redirected
Like PAM-based sign-on, no password is entered into the web page by the user,
and no password (or secret of any kind) is stored in the browser or
URL during authentication.
Successful authentication results in a new browser session at the site
in the same way as any other authentication method would,
returning credentials to the user's browser, setting an Authorization header,
or using any other suitable mechanism to cause the user's identity to
tied to subsequent web service requests.
While SSL/TLS is not required by TGMA during web-based authentication,
it is likely to be available and should therefore be used.
it will be needed to preserve the secrecy of the user's credentials
(in whatever form implemented),
as well as communication privacy and integrity,
and after successful authentication.
Drawbacks, Challenges, Risks, and Potential Vulnerabilities
The following are potential drawbacks and challenges of TGMA.
The mobile validator
An obvious drawback, compared to a password-based system, is that a
user must have ready access to his functioning validator.
This seems a small price to pay for the important gains in security,
as people very often carry a suitable device and have it at hand.
Also, using a device that is normally carried for other reasons
may be preferable to carrying an additional device only for
such as a hardware token required by many two-factor authentication systems.
There are places where users are not permitted to operate a mobile device,
however it is unlikely that users would need to authenticate
from such a location
(or, possibly, special-purpose validator hardware might be used).
The need for a separate device is obviously a drawback in situations
where some users do not have access to a device at authentication time,
requiring an alternate method to be provided.
Still, there will be situations where using a validator will never be
some user's first choice.
For example, for signing on to a desktop at home, where security is not
a significant issue for the user,
many people will prefer to enter a simple, easy-to-remember password than
to spend 10 seconds using their validator.
The need to perform an extra step to field the validator and authenticate,
compared with simply entering a password from memory,
may be perceived as irritating,
at least at first glance,
even given the many significant advantages.
Two-factor authentication methods are also comparably "inconvenient".
But few users would argue that recording passwords on paper and
searching for them at authentication time is a more satisfactory
Server-side implementation issues
A practical issue that arises is that the password-based authentication method
is ingrained in many system programs.
A typical system will have several different ways to start a session:
from a text-based console login or any of several
There are also likely to be several
Whether one of these programs uses PAM or not, it is likely to need
minor customization or replacement with a version that is able to use TGMA.
As currently conceived,
the authentication system is applicable only to interactive authentication
since user participation is necessary.
Adoption by prominent e-commerce web sites will be difficult,
Manual installation on a PC/Mac/Linux machine will be beyond the
abilities of many users,
so either it must fully automated or the machine must ship with the
functionality in place.
The system is probably not applicable to certain platforms,
such as for signing on to a tablet or other portable device,
because their system software is tightly controlled and no PAM-like
hooks are provided.
This may change, but until then they would need to be jailbroken or have
their manufacturers cooperate.
These devices are intended to be used as validators, however, rather than
Service providers can often reluctant to adopt a method they
did not develop themselves,
that is promoted by a competitor,
is not an official standard,
or that was not developed by an industry consortium.
Gaining official acceptance is difficult, expensive, and
Participants in a collaborative effort to adopt a new technology are
often at cross-purposes.
The system has several potential avenues for attack,
many of which it has in common with other password-management type systems.
Recall that no user passwords are stored by a sign-on validator,
so there are no passwords to be stolen.
While not ironclad protection,
sign-on can be bound to a device's unique hardware identifier,
making it more difficult to benefit from copying a sign-on validator's data.
The hardware identifier is given to the server at account creation time,
but not stored on the server, and obtained from the device's operating
system runtime API by the validator.
If a device supports persistently storing private per-app data
that cannot be copied (e.g., via backup),
a small amount of state information can be maintained
to cryptographically chain validation operations for an account such that
the resulting continuity ensures that the same validator has been used
for a sequence of authentication procedures.
Like a validator device,
hardware and software devices used for two-factor authentication
can also be stolen, broken, or lost, and must be carried with the user.
Like a password manager,
the critical requirement is to protect access to a validator and its data,
relying on the usual system password,
authentication required by validator (with inactivity timeout) and
storing data in encrypted form
(so that it cannot be easily copied from a running validator
or a device backup),
carefully using secure programming practices,
and so on.
Extremely careful implementation of a validator is mandatory,
to the extent of line-by-line auditing
Attention to ergonomic and accessibility practices are also important,
with an eye towards making all interaction with a validator as simple
and streamlined as possible.
The main difference between a password manager and TGMA is that
the former must store passwords that are transmitted to a system interface
in the same way as any other password and are susceptible to the same
kinds of attacks as any other password-based system,
particularly when a multi-device password sharing feature is present.
Besides trusting the password manager software,
it may be necessary for users to trust its vendor with
safekeeping of their passwords.
The most significant advantage of a password manager relative to TGMA
is that no server-side changes are needed.
When necessary, authentication for individual system interfaces that
demand a greater level of security can be strengthened by requiring
entry of a password on the validator (not the system interface)
at authentication time.
The password is only used temporarily by the validator during
the M-AUTH protocol and is not stored in the validator.
Here are some random points with respect to threats:
TGMA has been designed to be safe against attacks that might gain
access to a system interface.
Besides generic attack vectors,
the following major potential vulnerabilities must be addressed:
Theft of the sign-on validator's secret keys by stealing the
Theft of the sign-on validator's secret keys by copying a backup
It should be noted that if an attack on a server succeeds,
and the attack is able to obtain superuser privileges,
all subsequent actions taken by the server should be assumed to
have malicious intent; i.e., the system cannot be trusted until it has
been restored to a known-secure state.
A malicious server might try to trick the user by making it appear
that authentication succeeded even though the sign-on validator instructs
the user that it detected a
Users must be alert to this possibility.
This is sometimes addressed by configuring the server to display something
unique, such as a user-selected image, or present a user-selected
text phrase (sometimes in the form of a question).
Absence of this unique thing would be a sign that this is not the real server.
Theft is addressed in password managers by ensuring that the
validator's secret key database is always stored using strong encryption.
Steps should also be taken to limit any windows of vulnerability
while keys are used (decrypted), such as ensuring they do not appear
in log messages, core dumps, in the environment,
or on a command line.
DNS attacks targeting the server's hostname-to-IP-address mapping
and consequently the sign-on validator's connection to the server
This is addressed by the M-AUTH but there are also methods to
help protect against these kinds of attacks
Each server that stores and manages account information must be secure.
Unless there is a secondary method of authenticating,
a user who does not have access to his validator cannot sign-on.
On the other hand, a user cannot be forced to produce a password
for a TGMA account.
There must be a protocol to add and modify the account information
stored by the
In some situations, it may be possible to enhance security by
enforcing restrictions on the validator, such as its IP address or
apparent physical geolocation.
New and improved authentication methods are constantly being introduced.
Many of these have a biometric basis, such as
Google ATAP's security projects.
There is always a possibility that a new method,
or an improvement of an existing method, will catch on.
The main challenge to adoption is that server-side support is needed.
In contrast to password management tools,
this involves an initial commitment of system administrator time
(depending on how automated the installation procedure is).
There are two possibilities:
TGMA is installed on a service provider's (or user's) own servers,
whether for personal, corporate, institutional, governmental, customer,
or educational use,
TGMA is installed by a vendor on its products for its customers
(computer and technology OEMs), or
TGMA is installed as a service on a third-party server while
maintaining privacy and security.
Apart from hobbyests and professionals,
most users will have very limited system administration abilities.
Therefore, TGMA support must either be self-installing (and de-installing)
or pre-installed, and easy to configure.
Widespread adoption of a new authentication method,
even one convincingly more secure than the conventional password-based method,
will face significant resistance.
Perhaps the best way to begin is to prove TGMA's superiority
in a limited or niche context.
Today, users typically interact with web site authentication most frequently,
so acceptance in that domain in more likely.
Also, domains in which password-based authentication is impractical
or unusually awkward could be targeted.
It is important to recognize that an initial version must be
very carefully implemented, analyzed, tested, and documented.
Any major flaws could prove fatal to adoption.
In environments where requiring users to use TGMA is not a viable alternative,
TGMA authentication can be introduced in parallel with existing methods.
This would likely be necessary for testing and evaluation reasons in
Users might be given an incentive to switch to TGMA.
Password-based sign-on should eventually be disabled,
or users should be assigned a long, random password that is intended
to be secured in a safe place as a hardcopy for use as a back up only
To gain widespread user trust and confidence, it may be necessary to
get a big player involved as a partner or customer.
Potential customers would like to know that new technology
has been vetted by a recognized third party.
App store ratings and positive reviews are also important.
Personal computer users, in general, who want increased security
without having to create or remember passwords;
Niche computer users:
Parents of young children
Schools/Teachers with computer labs
Users with physical or mental disabilities
Enterprise computer users
The server side of the architecture, which is responsible for account
creation and management, as well as authentication support,
requires system administrator expertise to install and maintain.
Therefore, it is best aimed at corporate, institutional, and OEM customers,
and for use in special projects and custom installations.
manufacturers of devices such as routers and modems,
which usually have web-based or text-based interfaces for performing
administrative tasks, and who ship products with software installed,
would be prime adopters of TGMA,
especially since these kinds of products are often targeted
Medical devices, which have a critical need for strong authentication
but may not have an interface for hardwired password entry
implantable pacemaker or
may benefit from TGMA.
Although it is architecturally possible to add components,
each new component increases system complexity and opportunities for attack.
For instance, the web-based validator GUI adds a communication path between
it and the CGI implementation of the validator.
That path should be no less secure than the communication path between the
validator and the system interface
(how does the CGI validator authenticate the validator GUI?).
Unfortunately, this makes things such as providing the server-side component
as a service problematic.
A solution directed at authentication for Wi-Fi (802.11) routers
would be particularly attractive.
In WPA-Personal mode,
all devices using a Wi-Fi network must know the same (shared) password.
This creates an administrative nightmare when the number of devices
becomes large and the password needs to be changed, such as in the common
case where a single user must be denied access.
Because of the difficulty of doing this,
the change is simply not performed.
Meanwhile, users of the Wi-Fi network continue to assume that communication
is relatively secure.
In WPA-Enterprise mode,
this problem and several others
by having a
RADIUS server perform
to avoid issues related to RADIUS,
a device with suitable validator-enabled functionality could obtain
a new Wi-Fi network password from a server.
Disabling a user's access to the corresponding validator account would
deny that user access to a new Wi-Fi password so that only those with
appropriate permission could access the Wi-Fi network that requires the
This paper has described the design and architecture of TGMA,
an alternative to password-based authentication.
Owing to its many security weaknesses,
password-based authentication is long overdue for replacement
yet persists for many reasons.
Combining proven information security techniques and leveraging
a secondary communication channel,
TGMA addresses these weaknesses while minimizing elements that
cause both users and system administrators to be resistant to change.
Prototype implementations have been written to demonstrate TGMA
in several contexts,
but currently there is no native app available for mobile devices.
Development of such an app would be the logical next step but depends
on expression of interest and support from open source advocates,
commercial involvement, and/or funding.
The main technological challenge in the development of any secure system
is that every potentially insecure element of the design and implementation
must be identified, understood, and addressed.
A successful attacker only needs to find one hole that hasn't been
A related problem is where an attacker is able to run a
fake login, screensaver, web page, or system application that prompts a user
for a password.
If the password is entered by the user, an attacker may easily obtain a copy
Alternatively, the fake system interface may accept any password with the
intent of making the user believe that sign-on succeeded and capturing
subsequent user input (e.g., via man-in-the-middle operation).
This attack is thwarted by TGMA because 1) no password is provided,
2) the validator will not be able to authenticate the fake system interface
(unless the attacker has obtained a copy of the system interface's secret
and 3) the validator will connect to the true system interface (selected
by the user), which will be unable to corroborate the authentication
attempt because the attacker will not (with high probability) be able
to provide a valid passcode; the validator will not have a record of
the authentication instance associated with the passcode produced by
the fake system interface and will alert the user.
Unless the entire server has been compromised, this type of attack will fail.
Would like a fast way for a user to disable or erase
a sign-on validator's secret keys.
Apple's iOS platform has a mechanism by which a device's memory can be
After successful M-AUTH, either or both
parties could exchange/modify their keys or key-generating-key,
which would void any old instances of the validator's database.
Anyone reverting to an old database (e.g., a backup) would need
to resynchronize the account on the validator, which requires the original