In theory, authentication based on a username and password can be made sufficiently secure for most applications that do not require a high level of security. So why develop a new authentication architecture? As it is commonly used to authenticate users to web sites, the method is weak and susceptible to a wide array of attacks, sometimes leading to catastrophic consequences.

Passwords have proven difficult to replace.^[34] 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:

• A username, which identifies a user's account, is easily guessed or copied. An email address, common name or a derivation, phone number, account number, or employee number is typically used for this purpose. Usernames should be assumed to be public.^[1]
• Users are typically lax with respect to authentication, and computer usage in general, and they may:
  • select a password that can easily be guessed or brute-forced, or are required to use such a password because of server-side constraints, such as limitations on password length or character set,^[2]
  • reuse a password for different accounts,^[3]
  • not change a password sufficiently frequently,^[4]
  • transmit a password over an insecure communication channel,^[21]
  • record a password and keep it near where it is used, allowing it to be easily copied, stolen, or lost,^[29]
  • share a password with others,^[5]
  • unintentionally submit a valid password to the wrong server, or type it at the wrong time or into the wrong area, allowing it to be maliciously copied or accidentally leaked,^[32]
  • forget a password, requiring a password reset mechanism to be used that may itself be vulnerable to attack,^[33]
  • ignore security warnings emitted by user agents (such as those about an invalid SSL server certificate),
  • be careless about joining an insecure network, such as public Wi-Fi or a private network that has not been configured to maintain privacy,
  • unknowingly install software, extensions, or add-ons to their computer (browsers in particular) that can steal passwords, visit malicious web sites that can do so, or copy personal information that could compromise security.^[25]
• Theft of password files from servers is not unusual, with many high-profile incidents in recent years^[27] At worst, these files give an attacker plaintext passwords, but they more commonly enable off-line, brute-force methods to compute plaintext passwords.^[22] In addition to theft, once a company has been given a user's plaintext password there is no telling what may eventually happen to it, such as if the company is bought, has it stolen, sells it, or decides to change important architectural or implementation elements. In addition to password files, attackers have successfully stolen personal data from both government agencies and corporations, sometimes finding ways to bypass security by exploiting bugs. With respect to authentication, users sometimes derive their passwords or answers to personalized questions from this kind of information. Also, an untrustworthy service provider that possesses a user's plaintext password may be able to use it to gain access to the user's accounts on other systems (because people often use the same password for multiple accounts). A server that has been the victim of a successful attack may also be modified to leak passwords (Popular WordPress Plugin Comes with a Backdoor, Steals Site Admin Credentials). More generally, attackers that are able to collect large volumes of user account information may be able to use statistical methods to guide their future account cracking.
• Regardless of the quality of the password, sign-on implementations are themselves open to a variety of attacks, based on poor web site design, software or design bugs (such as "All four major browsers take a stomping at Pwn2Own hacking competition", "Game-over HTTPS defects in dozens of Android apps expose user passwords", "Staff breach at OneLogin exposes password storage feature, "OneLogin: Breach Exposed Ability to Decrypt Data", "This $5 Device Can Hack Your Locked Computer In One Minute), or insecure password administration. Trickery (e.g., phishing attacks^[6]) and highly-technical attacks, such as a man-in-the middle (MITM) attack, are also possible.^[7] To date, more than 90 percent of breaches have begun with a phishing attack, according to Verizon (Takeaways from the 2016 Verizon Data Breach Investigations Report).
• Users may sign-on from an insecure or infected computer (such as a shared or public computer), which may have surveillance software ("spyware", such as a keylogger or screen capturer) or malware installed (see "Trojanized open source SSH software used to steal information", "Beware of keystroke loggers disguised as USB phone chargers, FBI warns", "Keylogger Found on Nearly 5,500 Infected WordPress Sites").
• Users may sign-on over a network that may be susceptible to password sniffing, even when SSL/TLS is used.
• Legitimate system monitoring (browser history, system log files) may record passwords that may later be discovered by an attacker.
• Real-time visual surveillance methods ("shoulder surfing", video monitoring, mouse/cursor/eye tracking), may reveal passwords.^[8]
• Side-channel observation methods may reveal keys, passwords, or other information of use to an attacker.^[26]
• Devices are sometimes shipped to customers with a preset, default administrative password that is the same for all units. In the case of network routers and switches, a system administrator that does not set a new, strong password may leave his entire network open to attack (example: Cisco issues critical patch for Nexus switches to remove hardcoded credentials). While enforcing proper device configuration would help address this problem, adopting a better authentication method might eliminate the weakness entirely.

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:

• User and system administrator familiarity: the method is simple and intuitive to everyone. Users and system administrators are generally hesitant to adopt a new and less-trusted method. The importance of this should not be underestimated.
• Any alternative will necessarily have a learning curve, which will often be a barrier to adoption (i.e., people are lazy).
• Many alternatives are clunky to use, sometimes involving too many steps, requiring too much user interaction, or having poor accessibility characteristics.^[9]
• Users are understandably reluctant to learn and use a variety of different methods. Password-based sign on works the same way everywhere (especially when the same password is used!).
• Service providers may believe it to be prohibitively expensive to implement, "sell", and administer an alternative authentication method. Switching may simply be less important than other issues. Alternative authentication methods are primarily used in niche situations, mainly those requiring a very high degree of security, where an employer can dictate it, or where users are more technically savvy.
• There is a lack of standardized alternatives,^[10] which can be a critical requirement for some service providers. Service providers can be loathe to adopt a method they did not develop themselves or that is promoted by a competitor. Consider Microsoft's (defunct) Windows CardSpace. Authentication methods that depend on services provided by a third-party may be non-starters.
• In an enterprise single sign-on environment, or in any situation where an organization may have a large user base with a considerable investment in password-based accounts, it may be burdensome or expensive to switch to something new. Some organizations delegate authentication to a third-party service provider^[11], which may also be difficult for them to change.
• Most users will be unwilling to purchase a special-purpose device, particularly if that device cannot be used for all of a user's authentication contexts (no one will want a different one-time password generator for each of twenty different accounts), or if recurring costs are associated (e.g., periodic device or battery replacement).

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.

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

• Tend to be difficult for users to understand, execute, or trust, or have comparatively poor ease of use or limited applicability;
• Require too much administrative effort relative to username/password;
• Have a history of (or reputation for) core or tangential^[12] security problems, implementation issues, or frequent updates (which tends to make people wary of them, with some justification);
• Are susceptible to phishing and other social engineering attacks;^[24] or
• Are less flexible than TGMA.

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.^[35] 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 (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 usernames and (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.).

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.