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 M-AUTH protocol. 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 private information.] 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 be modified.
• A PAM authentication module running on any supported Unix-type system to provide a system interface for many PAM-capable system services, such as ssh,^[1] 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 emit output, 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 typical sign-on page is visited using any JavaScript-capable browser. 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:

1. Poll for an incoming connection on the well-known port.
2. Accept the connection, read and validate an AuthRequest message (from a system interface) or AuthValidate message (from a validator):
   1. If AuthRequest, queue the request.
   2. If AuthValidate, reject if a matching AuthRequest is not queued, otherwise initialize an authentication transaction for the connection pair.
3. Asynchronously and bidirectionally, forward data between a transaction's connection pairs until either side closes the connection.
4. Check for timeouts, deleting any queued requests that are too old and terminating any transactions that appear to have stalled.
5. 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 TCP connection between the validator and system interface. Whether communication based on UDP 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 account information (/etc/passwd). 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.

Most Unix-type systems support the Pluggable Authentication Module (PAM) mechanism, although the system services that use PAM vary on different platforms. The two main implementations are OpenPAM (for BSD-family systems, Mac OS X, and as an option on some Linux systems) and Linux PAM (for Linux-family systems). Different implementations of PAM may incorporate extensions and minor changes. It does not appear that Microsoft Windows platforms support PAM.^[2]

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, /usr/lib/pam, or /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. For instance, 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 (ftpd) uses PAM but does not fully implement a conversation function. In OpenPAM, this may be done via pam_info(), for example. 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. The FreeBSD login command (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 customizations.^[3]

Support for TGMA from a Mac OS X login or screensaver window has been partially implemented without having to modify standard system components. A rough version has also been demonstrated with the xlock(1) 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 (e.g., xdm, or equivalent), but it is likely that the standard (open source) software will need to be modified similarly.

On CentOS, 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 single threaded (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.

1. The user visits a TGMA sign-on web page where he is prompted for a username.
2. 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.
3. 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" parameter within 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.
4. 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.
5. 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 accordingly.

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. Also, 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.

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 authentication purposes, 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.

• Apparent Inconvenience
  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 experience.
• 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 display managers. There are also likely to be several screensaver programs. 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.
• Limitations
  As currently conceived, the authentication system is applicable only to interactive authentication since user participation is necessary.
• Deployment issues
  Adoption by prominent e-commerce web sites will be difficult, certainly initially.

  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.

• Platform applicability
  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 system interfaces.
• Not-Invented-here
  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 time consuming. Participants in a collaborative effort to adopt a new technology are often at cross-purposes.
• Potential vulnerabilities
  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 of code.^[4] 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.^[5] 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 secondary computer
  • 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 problem.^[6] 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.^[7]
• DNS attacks targeting the server's hostname-to-IP-address mapping and consequently the sign-on validator's connection to the server are possible (RFC3833). This is addressed by the M-AUTH but there are also methods to help protect against these kinds of attacks (DNSSEC).
• 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 sign-on validator.^[8]
• 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.^[11]

New and improved authentication methods are constantly being introduced. Many of these have a biometric basis, such as Microsoft's Windows Hello, Apple's Touch ID, and 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 any case. 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 (i.e., a recovery key^[9]).

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.

The market size for password management software? See Global Password Management Market 2015-2019

Potential classes of user include:

• 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. For instance, 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 for attack.^[10] Medical devices, which have a critical need for strong authentication but may not have an interface for hardwired password entry (e.g., an implantable pacemaker or insulin pump) 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 are addressed by having a RADIUS server perform 802.1X authentication.

Very briefly, 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 new password.

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 fully plugged.