1 files changed, 3 insertions, 3 deletions
diff --git a/content/entry/re-why-even-let-users-set-their-own-passwords.md b/content/entry/re-why-even-let-users-set-their-own-passwords.md
index 1f09c16..06e53fb 100644
--- a/content/entry/re-why-even-let-users-set-their-own-passwords.md
+++ b/content/entry/re-why-even-let-users-set-their-own-passwords.md
@@ -7,7 +7,7 @@ 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.
@@ -39,7 +39,7 @@ My browser also erases cookies, so I also have to log in every time, but this is
 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.
@@ -53,7 +53,7 @@ By logging in, users trade their 2FA for a 1FA session cookie. If the attacker c
 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."