Time-Gated Mutual Authentication
System Architecture: Part 7

DRAFT (15-November-2016)

Distributed Systems Software
Victoria, BC

Part 7

Prototype Implementation

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:

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.

PAM Authentication Modules and Standard System Services

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.

Web-Based Sign-On

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.

Drawbacks, Challenges, Risks, and Potential Vulnerabilities

The following are potential drawbacks and challenges of TGMA.

Here are some random points with respect to threats:

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:

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:

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.


  1. Bug in widely used OpenSSH opens servers to password cracking.
  2. But it is likely that the Windows authentication framework could use TGMA.
  3. On FreeBSD-type systems, the login class capability database login.conf is a complicating factor.
  4. If you're going to put all of your eggs in one basket, make sure you build a really good basket.
  5. LastPass Security Notice (15-June-2015) [] LastPass Reporting a Security Breach, Including Authentication Hashes and Salts [] Zero day hole can pwn millions of LastPass users, all that's needed is a malicious site [] LastPass security hole could have seen hackers steal your passwords
  6. 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 of it. 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 keys), 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.
  7. 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 reset remotely.
  8. 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 password.
  9. But may not always be the best alternative: Apple drops Recovery Key in new two-factor authentication for El Capitan and iOS 9.
  10. "Dissecting Linux/Moose", describes a worm that infects certain routers through weak Telnet passwords.
  11. "MIT Develops Accurate System for Tracking People, Objects via WiFi"