Why even let users set their own passwords?

Today we seem to be living through a war on passwords. This is manifested in various ways; in its most passive form, it takes the form of people blogging about how passwords are bad. The more material changes are the general trend towards no longer treating passwords as a sufficient condition for access in favour of either mandatory “2FA” or, where 2FA is not used, risk-based authentication, in which some extra authentication step is non-deterministically and randomly demanded.

This step is commonly something like “enter the code in an email we just sent” when trying to login. Since this process is literally the same as most password recovery processes, it raises the question of what the point of a password is in the first place if you always have to go through this process when trying to login.

Often this will be combined with fallacious notions such as “remember this device”, the idea being you only have to go through all this the first time when logging in from a particular device. This idea is fallacious because the web has no notion of a “device”, and this is a very intentional design choice made for privacy purposes. We are literally living through the gradual phase-out of third-party cookies, amongst other functionality, specifically to try and prevent this sort of thing, so why do web developers persist in believing in this fiction of a “device”? My own browser erases all cookies from an origin immediately after the last tab from that origin is closed, so these sites are convinced I am logging in from a new “device” every single time, and then demand I respond to one of these challenge emails.

Essentially these sites consider passwords so worthless as a form of security that they essentially don't meaningfully allow people to have one anymore. The login flow and the password recovery flow are essentially the same, the UI just pretends otherwise. Other examples include PayPal, where you can literally enter a credit card number to prove your identity and reset your password(!). In other words, knowing your credit card number is considered a stronger or equal proof of identity than either knowing your password or being able to receive an email.¹

While at the same time every website for the masses now seems to be designed around the assumption that everyone is going to set their password to “password1”, web-based HTTP APIs are also widely popular nowadays. These services almost invariably perform authentication via use of a token or “API key”.

An API key is basically a password, except that it is randomly generated by a website with a large amount of entropy and thus assumed to be secure. A given website might obnoxiously refuse to trust in my ability to set a secure password, assume the 24-character randomly generated password I keep in my password safe is insecure, and demand I complete an email challenge every time I login because I actually bother to exercise control over browser privacy and persistent cookies, yet that same website is happy to let me authenticate using an API key for API access as a single authentication step. No “2FA” here.

API keys are used to secure the highest-stakes APIs that exist today — all of AWS's services, for example. Yet while API keys seem to be considered an entirely reasonable and industry standard design approach, passwords are now considered the unwelcome black sheep whose role as a sufficient criterion for authentication is viewed with increasing dubiousness. (Moreover, all website login schemes ultimately rely on some kind of session cookie, which is similar to an API key in the sense that it is a high-entropy site-issued bearer token. In other words, all website authentication schemes, “2FA” or not, ultimately rely on the ability of a client to be enrolled in and use high-entropy site-issued bearer authentication tokens as the sole criterion of access.²)

The fundamental premise is the same: provide token, gain access. It seems to me that the basic problem here with passwords is that passwords are assumed to have been chosen by users and users are assumed to be bad at choosing good passwords.

There are agreed best practices for the handling of passwords, namely, to not reuse passwords between accounts, use randomly generated passwords, and keep those unique passwords for each account in a password safe. This raises the question: if the industry agrees this is the (more or less only) correct way to handle passwords, why actually allow users to set their own passwords?

Rather than allowing a user to set their own password, passwords can be issued in exactly the same way as API keys are now: a high-entropy password is randomly generated by the issuing website, and the user is shown the password once only and asked to record it. If the password is lost, a new password must be generated using the same process. The user cannot choose their password, but can get a new randomly generated one in the event of compromise. The password essentially becomes indistinguishable from an API key.

If we consider the password safe usage model to be the only reasonable way to use passwords properly, there doesn't really seem to be any reason to allow any other usage model than this. There's not really a good reason for a user to be able to set their own password unless they want to set their password to something lower in entropy to make it memorable, or reuse it between sites, both of which are deviations from the “best practice” password safe usage model.

With this model of password issuance, there is less need to constantly second-guess the user's security with hazardous approaches like risk-based authentication. Interestingly, however, it can be argued that this model is in effect already widely deployed: namely in the form of TOTP “2FA” support.

In enrolling in TOTP-based 2FA with a website, you are given a high-entropy randomly-generated secret and, for subsequent logins, are required to prove possession of this secret. In other words, it's a site-generated non-customisable “password” in much the same vein as I propose above. Moreover, sites which support TOTP usually use a user's enablement of it as a “not an idiot” flag and disable any non-deterministic risk-based authentication mechanisms they may use for people without TOTP enabled. This is congruent with my premise above that guaranteed use of a high-entropy secret obviates the need for additional authentication.

Since the user-specified password functionality is now seemingly so distrusted as a widespread industry practice, it raises the question of why not just either use only TOTP for login, or issue a password in the same way that TOTP secrets are issued: randomly and non-customisably.

The only discernible difference between TOTP and a site-generated password is in how knowledge of the secret is proven. With TOTP, knowledge of the secret is proven without sending it to the website. With a site-generated password, knowledge of the secret is proven by sending that secret to the website. This is a slight security benefit to TOTP. It doesn't seem to provide any useful security against a compromised or impersonating website (an impersonating website can just forward the TOTP challenge value to the real website and use it to login as the user), so its main benefit seems to be to avoid having the device the user is logging in as be able to glean the secret, in the event that device is compromised. This is a potential upside, though since on successful login the compromised client device has access to anything gated by that login anyway, the benefit seems dubious.

It is interesting to note that TOTP ultimately can be viewed as just another secret authentication token, like a password, yet is widely referred to as “2FA”. Having two passwords isn't “2FA”; 2FA about having authenticators from two different categories of {what you have, what you know, what you are}.

If TOTP is used “correctly”, meaning that the TOTP secret is enrolled onto a different device than the one that contains your password safe, 2FA is more or less realised — arguably. (You could also argue it's two copies of “what you know” but with data partitioned between two devices which are unlikely to be simultaneously compromised. This demonstrates that the {what you have, what you know, what you are} triad is not necessarily the be all and end all of authentication scheme security level classification.)

Of course, you don't necessarily know if someone is using TOTP “correctly”. For example, whenever I register on some random site which offers TOTP, I enable it and then put the TOTP secret in the same password safe that contains the equally high-entropy password I chose. This seemingly pointless act is obviously not 2FA. The reason I do this is for two reasons:

1. it seems to increasingly serve as an “I'm not an idiot” flag and disable stochastic risk-based authentication based around an assumption people can't choose secure passwords, in which I might randomly be asked to an additional challenge the potential necessity of which was not documented at registration time, and which I may or may not be able to complete, potentially resulting in account lockout;

2. it often seems to effectively disable password recovery flows, or at least render them moot, making account recovery more difficult. Since I don't lose my secrets I'm happy to assume responsibility for the possibility of permanently locking myself out in exchange for higher account security and disabling email as the “master key to all accounts”.

While my own usage patterns are probably somewhat esoteric, in general it's expected people will store TOTP secrets on a smartphone. However this again raises questions about whether it really is “2FA” when you consider many people may be accessing a website from their smartphone in the first place. In fact, it's likely that a lot of TOTP-based “2FA” is not really 2FA at all because the user's browser and password safe (e.g. the browser's built in saved password functionality) and TOTP secret are on the same device and both instances of “what you know”.

This isn't the only case of websites demanding “2FA”-that-isn't. Many supposed cases of “2FA” are really 1FA where the single factor required for authentication is considered to lie in a better category than “what you know”, or where there are two factors at first glance, but one factor can be used to reset the other factor.

For example, a site which requires a password and email verification for each login is not 2FA if access to the same email account can be used to reset the password; this scheme is no more secure than just requiring email verification per login. Another example is if a site tries to insist on verifying logins using SMS messages sent to a user's phone number. Since this (particularly bad) design is based on the false premise that a user's phone number is more secure than an email account or any password, such sites will often allow a reset of all the other factors (like a password) by access to this phone number alone. This is quite literally 1FA, just with a different single factor.

This again seems to reinforce that the major benefit of pushing people to enable TOTP is to actually have them adopt a secure “password” and not actually “2FA”, which is often not actually realised.