Distributed Systems Software
Passwords have proven difficult to replace. 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.
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.
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.
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, 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:
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).
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. 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.
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 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.
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.).
A secure method for signing in using quick response codes with mobile authentication 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. 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.
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.
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.
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).