summaryrefslogtreecommitdiff
path: root/static/resource
diff options
context:
space:
mode:
Diffstat (limited to 'static/resource')
0 files changed, 0 insertions, 0 deletions
;id2=ba9691f0a14e5d908d24db39c37f44f2873a51ae04f9818007ec247d0cf4df27'>content/entry/re-why-even-let-users-set-their-own-passwords.md99
1 files changed, 99 insertions, 0 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
new file mode 100644
index 0000000..e03b96a
--- /dev/null
+++ b/content/entry/re-why-even-let-users-set-their-own-passwords.md
@@ -0,0 +1,99 @@
+---
+title: "Re: Why even let users set their own passwords?"
+date: 2023-08-17T00:00:00
+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://www.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 l