1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
---
title: "Re: Why even let users set their own passwords?"
date: 2023-08-17T00:00:00
tags: ['computing']
draft: false
---
This entry is a yet another commentary on an article written by Hugo Landau, titled "[Why even let users set their own passwords?](https://www.devever.net/~hl/passwords)".
> "Today we seem to be living through a war on passwords. This is manifested in various ways ... 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."
There are several flaws with this email token approach to account security as described by Hugo.
First, as Hugo points out, since the alternate login flow (password recovery) only requires the email token, the password not only becomes a pointless inconvenience that increases system complexity with no security benefit, but it also gives the user a false sense that their account is protected using two-factor authentication when it's not.
Even if the email tokens were truly two-factor, most users probably access email from the same device they use to log in to online accounts anyways. So it still wouldn't be "proper" two-factor.
Second, these email tokens actually give the attacker several more avenues to gain account access, and in ways the user likely isn't considering, doesn't know about, and has no ability to mitigate. Here are a few:
* Guessing the user's email account password
* Completing the user's email account recovery process
* [Phishing](https://en.wikipedia.org/wiki/Phishing "Phishing") the user's email
* Compromising the user's email server
* Phishing the user's email server administrator
* Compromising the user's email server's cloud hosting provider
* Compromising the user's email server's cloud hosting provider account
* Phishing the user's email server's cloud hosting provider
* Completing the email server's cloud hosting provider account recovery process
* Breaking into the user's email's domain name registrar account
* Completing the user's email's domain name registrar account recovery process
> "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."
I don't see the "remember this device" terminology as a problem. I think it helps non-technical people understand what's going on while technical people understand what it's doing anyways.
My browser also erases cookies, so I also have to log in every time, but this is the desired behavior.
I agree that using email tokens as a login system is problematic, but that's a separate issue. I agree that websites shouldn't use third-party cookies, but third-party cookies aren't required for "remember this device" that I'm aware of. So it's not exactly clear to me what Hugo's complaint is here or what they want done about it.
> "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 by programs and automated systems, so they can't use 2FA. As Hugo observes, this nullifies 2FA. This is why API key access should be limited by default so someone with the key can't just change the account login credentials as they could if they'd logged in normally with 2FA. Some online services do limit the scope of the API by default, but some don't. They ought to.
For many non-security-minded people, it doesn't even occur to them that enabling API keys cancels their 2FA. Websites ought to display a warning inside a confirmation dialog when users try to create an API key that would circumvent 2FA while they have 2FA enabled, or when they enable 2FA while having an API key.
> "...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."
By logging in, users trade their 2FA for a 1FA session cookie. If the attacker can steal the session cookie, that's all they need to assume control over the account.
Some online services are keen on this and require an additional 2FA step to change important account settings while logged in, such as account credentials. This extra 2FA step still doesn't make the account fully secure, but it's better to have it than not and many websites don't have it.
> "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."
I agree. I also think it would be a good idea to include a notice telling the user to store the token in a password manager. Some might object "You can't require users to store randomly generated passwords. Since they can't remember it, they'd take a picture of it which would be synced to Google Photos and Apple iCloud. They'd write it down in an insecure location. They'd save it in a text file which they'd accidentally delete. They'd do everything except learn to use a password manager."
Based on my IT experience, I completely agree. The average user would simply ignore the advice to use a password manager and do whatever they wanted anyway. But they already do the same with passwords they set themselves. While websites have a duty to take every reasonable step to secure user accounts, in the end, they can't stop users from shooting themselves in the foot if they insist on doing so. So they may as well make things as secure as possible on their end by generating secure user passwords rather than allowing them to set poor ones.
On the server side, generating secure user passwords would have another benefit that Hugo didn't mention: One could store user passwords run through a single iteration of a cheap, fast [hash function](https://en.wikipedia.org/wiki/Hash_function "Hash Function") rather than using a relatively expensive [key derivation function](https://en.wikipedia.org/wiki/Key_derivation_function "Key Derivation Function") that needs its iteration count constantly updated and requires storing a [salt](https://en.wikipedia.org/wiki/Salt_%28cryptography%29 "Cryptographic Salt"). [Rainbow tables](https://en.wikipedia.org/wiki/Rainbow_table "Rainbow Table") and password cracking software would be so useless that no sane attacker would even attempt it.
> "... 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."
While I'd prefer to use [TOTP](https://en.wikipedia.org/wiki/Time-based_One-time_Password "Time-Based One-Time Password") codes instead of a password for online services, I agree that the security gain would be dubious when compared to secure, server-generated passwords.
> "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”."
Email being the "master key to all accounts" irks me too. I understand why online services make it so and it may even be necessary as an emergency fallback measure for restoring user account access post server compromise, but [email is insecure](/2020/10/29/using-email/ "Using Email") and cannot be secured. 99.99% of users don't even legally own the domain their email is registered under, so they don't own their email either. That means the "master key to all their accounts" is an identifier they don't own and can be arbitrarily taken away. Not good.
But if you don't allow users to reset passwords via email, what else is there? SMS codes? [Phone numbers are even less secure than email.](/2023/08/10/re-phone-numbers-must-die/ "Re: Phone numbers must die") Security questions require storing sensitive information about users that inevitably gets leaked by hackers.
What I'm about to suggest might sound harsh, but I think it's the best way forward. I think online services should just enforce random server-generated passwords as the only credential required for login and if a user loses it, they have to create a new account.
I know, I know. People would be getting locked out of their accounts left and right, but I think part of the reason the average user is so incompetent is because online services are designed with the expectation that they are.
If we want competent users, we should stop catering to the least common denominator. Let's set this bare minimum standard instead: If a user can't figure out how to save their login credentials to a file and create a backup in case of emergency, or at least find a trusted third-party to do it for them, maybe they're not competent enough to use the service.
If it's important that they be able to access the service even if they're technically uninclined, then the service should be available through offline means.
There are online services that already use secure, server-generated passwords, such as the VPN company [Mullvad](https://mullvad.net/en/account/create). Granted, it's easier for them to pull it off given the type of service they offer, but online services have to set the bar somewhere or else website login will continue to be inconsistent and suck.
> "... 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."
I think the reason websites' login systems often seem confused about what they're doing and we get all these strange, poorly-designed login schemes is that they're trying to accomplish two mutually exclusive goals simultaneously:
* Make certain that tech-illiterate users never get locked out of their accounts
* Secure user accounts and associated data against attackers
You can try to strike a balance between these two options with [risk-based authentication](/2023/08/10/re-against-risk-based-authentication-or-why-i-wouldnt-trust-google-cloud/ "Re: Against risk-based authentication (or, why I wouldn't trust Google Cloud)"), but you'll just end up with indeterminate login criteria which locks out tech-illiterate users and/or collecting sensitive user data which [you cannot secure in the long run](/2021/01/18/consumer-data-protection-is-a-distraction/ "Consumer Data Protection is a Distraction"). Supporting [Web Authentication](https://en.wikipedia.org/wiki/WebAuthn) is a good idea, but the tech-illiterate user will get locked out when their [FIDO](https://en.wikipedia.org/wiki/FIDO_Alliance) device breaks or gets lost or they buy a new computer with a different [TPM](https://en.wikipedia.org/wiki/Trusted_Platform_Module).
In conclusion, I'm highly skeptical that there's any way of creating a secure online login system that also ensures tech-illiterate users never get locked out. Designing a login system around the assumption that the user can't even safeguard a password or hardware key is a total non-starter for account security and teaches users that it's okay not to know what they're doing because online services cater to the clueless.
Online services should instead start with the assumption that the user has a basic level of computer competence and force them to use passwords that are securely generated on the server-side with an optional 2-factor TOTP instead of cooking up poorly-designed, misleading, insecure, non-deterministic, data-hazardous login systems.
Long term, we need to deprecate passwords and move towards asymmetric keys for authentication. There is an attempt to bring asymmetric-key-based authentication to the Web with the Web Authentication standard, but almost no one has FIDO devices, a lot of people still have old CPUs without TPMs, and I haven't found any purely software-based solution for using WebAuthn.
So, for the moment, forcing WebAuthn on users seems less practical than forcing secure server-generated passwords onto them. Until WebAuthn becomes a viable option or the Web itself is replaced with a [more secure standard](/2023/02/14/article-the-internet-is-broken/ "[Article] The Internet Is Broken"), secure server-generated passwords would be a good next step.
|
