Time-Gated Mutual Authentication
System Architecture: Part 2

DRAFT (23-March-2017)

Distributed Systems Software
Victoria, BC


Part 2


Motivation

Why develop a new authentication architecture? In practice, authentication based on a username and password is recognized to be weak in many ways. Alternative authentication methods have not gained traction, except in limited contexts. Each method makes different design choices between security and usability. The main challenge preventing an alternate authentication architecture from replacing password-based authentication is that it must provide obvious security advantages without even the perception of decreasing ease of use (especially for users, but also on the server side). There are other important factors, such as maintaining personal privacy and low cost.

Password-based Authentication

The password-based authentication method is by far the most popular, despite having been proven vulnerable to a wide variety of attacks. As it is usually employed:

Also, there are situations where strong authentication is desirable but where password entry is inefficient, impractical, or difficult to provide or perform. For example, entering a long password (and all other things being equal, a longer password is a better password) on a touch screen device is annoying and prone to error.

Password-based authentication remains ubiquitous, despite the availability of more secure alternatives, for the following reasons:

We might conclude that users are willing to trade security for simplicity and ease of use. Consequently, for fear of losing potential customers, service providers are reluctant to eliminate password-based authentication.


Alternative Authentication Methods

Many alternatives to password-based authentication have been developed. Even the most well-known of these:

More secure authentication methods, especially those based on one-time passwords, have been available for many years (e.g., opie(4), Google Authenticator). Some one-time password schemes depend on a hardware-based password generator (e.g., Authenex OTP Token Products, RSA SecurID). others are software based, requiring a user to obtain software ("an app") for their mobile device. If the authentication method is based on a standard, such as RFC 4226 or RFC 6238, many free apps are available. Some proprietary server-side software will only interoperate with that vendor's hardware tokens, however. For each compatible account on a server, a corresponding account on the app is created and synchronized with the server. To sign on to a server, the user selects the account and asks the app to display a one-time password, which the user submits to the server along with the account's username and (optionally) a password shared by the user and server. Hardware tokens can be relatively expensive and, due to their non-replaceable battery, have a limited lifetime.[13]

Some banks, retailers, and service providers (e.g., Apple, Google) offer an optional two-factor authentication method for their web sites. These methods typically require the user to have a device that can either run an app to produce a one-time password for the particular site, as described above, or receive a text message that contains a one-time password. Personalized questions are sometimes used as a secondary authentication factor,[14] with dubious effectiveness. Apart from the expense to implement the technology and provide software apps or hardware tokens (which the majority of users will not be willing to pay for directly), these businesses fear that they will lose customers if they deprecate passwords.

A simple mutual authentication, two-factor authentication can follow this general methodology:

  1. The user enters his username into the authentication form and submits it.
  2. The system receives the authentication request and finds the corresponding account, previously associated with an email address or SMS address, which is the user's registered point of contact.
  3. The system displays a randomly-generated server passcode (e.g., letter-digit-letter-digit) and sends an authentication request message to the user. The message contains the username, one-time password, time and date, system name, and other contextual information. It also contains the server passcode.
  4. The user compares the server passcode in the message to the displayed passcode, which must match. He also examines the other descriptive information in the request message for correctness. Confident that everything is correct, the user proceeds to the next authentication step where he enters the one-time password in the authentication form and submits it.
  5. Authentication succeeds if the user provides the correct one-time password within a certain time period after transmission of the authentication request message.
The method improves security because:
  1. To convince a user of authenticity, an attacker needs to 1) determine the random server passcode, 2) know the user's point of contact, and 3) send a convincing message with correct contextual information.
  2. The user is assumed to have control over the email or SMS account in order to receive the system's message.[30]
  3. Only the user and system should know the one-time password and the server passcode.

Many variations of this method are possible. For instance, the passcode can be transmitted to the user's point of contact where application-specific software on a mobile device displays it as an image. A system interface can then scan the image to identify the user and her physical location. This approach is being adopted by banks for accessing their ATMs (US banks to test ATMs which accept your smartphone instead of cards).

It has been reported that Google is developing a method very similar to this for mobile devices.

Probably the biggest potential vulnerability of this method is a phishing attack that can easily be mounted if the attacker knows (or can guess) the user's point of contact; many systems use an email address as a username. To avoid this attack, the message would need to be sent to a different, less public email address. This quickly becomes problematic for users as the number of email addresses that must be carefully managed for validation purposes increases. If a user's browser or its system is compromised, an email message might be intercepted or modified on the compromised system, making an authentication procedure susceptible to manipulation.

This points in favour of using SMS rather than email for this purpose, but telephone numbers can often also be found with a little effort. Also, privacy-conscious users may be unwilling to share their telephone number (possibly more than one) with untrusted companies and organizations.[23] While it may be a good approach in certain contexts, as a general solution sending a text message to an arbitrary user may be difficult or expensive on the server side, and may involve a transaction fee. For the user, receiving an SMS will require either cellular service or Internet connectivity at authentication time.

In an environment with relatively low security requirements, this method may be sufficient. But a greater degree of security requires a more sophisticated protocol between the system and user, which necessitates some form of computational assistance, such as employing a mobile operating system's notification mechanism.[28]

Because they can require employees and contractors to use two-factor authentication products that employ one-time passwords to remotely access their systems (such as Entrust IdentityGuard or RSA SecurID), government and corporate systems tend to do so much more commonly.

The technology to implement two-factor authentication is mature, but its adoption is still comparatively small in scale. Notably, it does not solve some important security-related attacks.


Password Managers

Password managers (also called password vaults and password wallets) and other "password assistants" are typically used with web browsers to automatically complete username/password forms.[15] Some can also be used in other authentication settings. A variety of convenience and security features are sometimes available, such as synchronizing password databases across a user's devices and using two-factor authentication to access the password manager (Examples: LastPass, PasswordBox, DashLane, Password Safe). Because a password manager stores and inserts passwords on behalf of the user, passwords can be as strong as permitted by the system interface.[16]

Password managers may have important practical drawbacks and significant security issues, particularly when integrated with other software, such as web browsers. Careful, correct design and implementation is critical since an error may reveal (plaintext) passwords that can be copied and used by an attacker.[17]

When a password manager is used with a web browser, an extension to an off-the-shelf browser is needed, and (plaintext) passwords continue to pass through the browser, where they can potentially be captured by an attacker.

In some contexts, adding an extension to a web browser may be forbidden or impossible. Not all web sites support password manager functionality (Websites, Please Stop Blocking Password Managers. It's 2015.).


Systems Similar to TGMA

In the common case of signing on to a web server using a standard web browser, there are alternatives to password-based authentication over SSL/TLS, but they require implementation of a client-side protocol. This necessitates browser customization, perhaps via a special extension or add-on, JavaScript, or the use of a proxy server. Perhaps because of browser complexities and incompatibilities, or simply the hostile environment in which they must function, these approaches have a poor security record and so do not provide a satisfactory solution. We therefore have good reason to assume that authenticating via a web browser is inherently insecure, allowing attackers to exploit weaknesses and bugs to directly or indirectly steal passwords. [18]

A secure method for signing in using quick response codes with mobile authentication[19] describes a system for web-based authentication that is superficially similar to TGMA and shares some of the same goals. It requires a "helper device" and uses QR codes integrally. The main benefit of that system appears to be to increase privacy by moving entry of a username and password from a possibly insecure interface to a personal device.[20] Unlike this system, TGMA is based on M-AUTH and encryption, using secure and peer-reviewed algorithms. Furthermore, TGMA eliminates user passwords during sign-on, does not rely on QR codes (but they can optionally be used for reasons of convenience and accessibility), and is not specific to web-based authentication.

The Secure Quick Reliable Login (SQRL) system seems to be closest to TGMA. This system employs a separate app, such as on a smart phone, and cryptographic signatures. The resulting authentication is for anonymous identification of users, however; a user is not associated with a site's account, but rather with a unique public key. A user will present the same public key on every visit to a particular site, but a different public key to different sites. This has usage and security advantages similar to those of TGMA, but addresses a different problem: pseudonymous authentication. Because of this, prior account creation is not needed but consequently the mutual authentication feature is weakened. Also, SSL/TLS is used between the device that functions as the validator and the authenticating site. TGMA can provide a similar form of pseudonymous authentication, but an initial account creation step is required (SQRL might also require such a step if a handle or screen name is to be attached to the public key identity).

Continued in Part 3.


Footnotes

  1. Knowing the username for an account makes an attacker's job somewhat easier, but a service provider's main motivation for keeping usernames confidential should be to maintain user privacy. Sometimes information that ought to remain private, such as bank card numbers, are used as usernames. This kind of information is potentially useful to attackers. Some communication/authentication protocols do not treat a username as secret information. A properly designed authentication procedure will not reveal if a username is valid unless authentication is successful.

    Personal questions and answers are sometimes used as a confirmation of identity secondary to passwords. They are an attractive target on servers because they can sometimes be used to reset a password and to commit identity theft.

  2. SplashData's fifth annual 'Worst Passwords List' [] "What's Your Pa$$word? Secure Your Organization by Securing Your Accounts". To help protect against password guessing, authentication mechanisms should always rate limit sign on attempts. After a small number of unsuccessful attempts, authentication requirements for the account should be increased or the account locked.
  3. According to "A Large-Scale Study of Web Password Habits", the average user has 6.5 passwords, each of which is shared across 3.9 different sites, and each user types an average of 8 passwords per day. One analysis suggests that a minimum of 15% to 20% of users reuse their username/password at "numerous" sites (Over 20 million user accounts hacked via duplicate logins from other sites).
  4. Two thirds of public sector workers keep quiet on major security breaches. It's not clear that frequent password changes are desirable: Frequent password changes are the enemy of security, FTC technologist says
  5. From Passwords revealed by sweet deal: more than 70% of people would reveal their computer password in exchange for a bar of chocolate and 34% of survey respondents volunteered their password when asked without even needing to be bribed.
  6. Phishing [] Half of people click anything sent to them [] "Scandinavian Attack Against Two-Factor Authentication" [] "Protect your Google Account with Password Alert" [] closely followed by "Google's new version of Password Alert blocking bypass is bypassed".
  7. "Man-in-the-Middle Attacks"
  8. For instance: "The Spy in the Sandbox - Practical Cache Attacks in Javascript" [] "Watch out: If you've got a smartwatch, hackers could get your data".
  9. Authentication Method Characteristics:

    The "ultimate" authentication method is one where a user is identified, virtually instantaneously and with great accuracy, in any context, without the user having to do or remember anything, and without security, privacy, cost, or availability issues. This "holy grail" of authentication does not currently exist.

    In the absence of perfect human recall, all strong, general-purpose authentication methods available today impose some degree of inconvenience on users, whether it requires carrying a hardware device or managing slips of paper that record passwords. The goal of a new and better authentication method is not necessarily to have all of the characteristics of an ultimate method but rather to achieve trade-offs between them that are acceptable to many users.

  10. The Fast IDentity Online (FIDO) Alliance hopes to address this. Its lengthy membership list includes major financial institutions, retail companies, and hardware and software vendors. This suggests that there is keen interest in better authentication methods.
  11. Some examples: Stormpath, Firebase, iRoam, and Clipperz (AGPL v3 licensed). It is curious that some organizations and their users are willing to trust user account management (and raw passwords) to a third party, given the potential for opaque security practices, legal issues, etc.
  12. "HTTPS-crippling attack threatens tens of thousands of Web and mail servers"
  13. By one informal estimate, the cost of adopting a two-factor authentication method (likely through something like Microsoft's Active Directory) is approximately $50 USD per user. Expect to also pay between $25 USD and $50 USD for each hardware token.
  14. Telephone-based authentication methods may ask a customer questions to confirm identity, such as:
  15. For instance, a password manager is built in to Firefox.
  16. LastPass, for instance, has a "premium" version that includes some account sharing modes. Apparently, it uploads encrypted account and password information to their servers.
  17. Many Chrome extensions contain malware [] Cracking-Resistant Password Vaults using Natural Language Encoders [] The Emperor's New Password Manager: Security Analysis of Web-based Password Managers [] On The Security of Password Manager Database Formats [] `Billions' of records at risk from mobile app data flaw.
  18. Security vulnerabilities: Firefox [] Chrome [] Internet Explorer [] Safari. Also: Dangerous Internet Explorer vulnerability opens door to powerful phishing attacks [] Stop Using Safari And Update iOS To Avoid Apple's Critical 'Gotofail' Security Bug [] Firefox is still the least secure web browser [] Researchers identify major security and privacy issues in Popular China Browser Application, QQ [] A Chatty Squirrel: Privacy and Security Issues with UC Browser [] Baidu web browser branded a privacy nightmare [] Browser Autofill Profiles Can Be Abused for Phishing Attacks [] Your browser might be filling in hidden fields and giving away your secrets [] LastPass Bugs Allow Malicious Websites to Steal Passwords []

    Browser vendors do not shoulder the entire responsibility for these security problems. The many standards that browsers and related software follow are complex, ever changing, and sometimes contain errors or omissions. Users configure and use browsers (and other software) without much understanding or regard for security. Furthermore, they are often conditioned to ignore messages, warnings, and errors produced by software.

    Some browsers have the ability to run an external, "containerized" local function, only in very limited circumstances and at a limited privilege level, being passed parameters and returning a result (e.g., as JSON documents). It may be possible to use this to interact with the user (e.g., to get input) securely, in theory, if it can be done in such a way that it would be impossible for anything loaded into the browser or any other such container from inspecting its operation. For Firefox, some existing starts in this direction, such as a crude implementation or using official mechanisms Add-on SDK, js-ctypes. Obtaining passwords from users in a more secure way only addresses part of the problem, and there are reasons for not wanting to customize a browser that are not directly related to security, not the least of which is the all too common problem of supporting multiple web browser types and versions, which tend to have arbitrary incompatibilities.

    Mobile devices usually provide a web browser, though they are generally less feature-rich and extendible compared to desk-top browsers. They are therefore also susceptible to browser-based attacks, in addition to attacks based on rogue apps, authentication weaknesses, or synchronization vulnerabilities (Anywhere computing makes 2FA insecure on iOS and Android).

  19. "A secure method for signing in using quick response codes with mobile authentication" [PDF].
  20. International Journal of Student Research in Technology & Management, Vol. 1, No. 1, March, 2013, pp. 1-11. It is not clear if this system does away with user passwords, exactly which attacks the (imprecisely-described) protocol defeats, and to which attacks it remains susceptible. There is an implication that asymmetric cryptography is used but it seems rather that two randomly-generated strings are used to correlate an instance of a web sign-on procedure with a URL embedded in a QR code and submitted by a helper device.
  21. It is difficult for knowledgeable users, and practically impossible for the average user, to know with certainty whether a password will be submitted securely from a random web page.
  22. See: Statistics Will Crack Your Password. Precautions such as bcrypt or scrypt are possible, at the cost of additional computational resources at authentication time.
  23. How about sharing your photo, perhaps regularly, with some corporation? See: Amazon wants to replace passwords with selfies and videos
  24. Typosquatters Target Mac Users With New '.om' Domain Scam [] QRLJacking: A new attack vector for hijacking online accounts
  25. Chrome Extension Caught Hijacking Users' Browsers, NoScript and other popular Firefox add-ons open millions to new attack
  26. How spies, anyone can grab crypto keys from the air, Smartphone WiFi Signals Can Leak Your Keystrokes, Passwords, and PINs
  27. Unauthorized Cross-App Resource Access on Mac OS X and iOS [] Yahoo confirms major breach - and it could be the largest hack of all time[] Big data breaches found at major email services [] LinkedIn user? Your data may be up for sale [] How LinkedIn's password sloppiness hurts us all [] Hackers Stole 65 Million Passwords From Tumblr, New Analysis Reveals [] Hackers stole over 43 million Last.fm accounts in 2012 breach [] 98 million leaked from 2012 breach of "Russia's Yahoo" [] Another Day, Another Hack: 100 Million Accounts for VK, Russia's Facebook [] Hacker puts 51 million file sharing accounts for sale on dark web [] Hacker steals 45 million accounts from hundreds of car, tech, sports forums.
  28. Google is making two-step verification less annoying
  29. Study finds Password Misuse in Hospitals a Steaming Hot Mess
  30. Using SMS as an authentication factor may be losing favour. See DRAFT NIST Special Publication 800-63B, Digital Authentication Guideline, Section 5.1.3.2: Out of Band Verifiers.
  31. Here are just a few recent corporate security breaches: Verizon, Banner Health. Apparently, little is being done to improve security.