diff options
Diffstat (limited to 'content/entry/re-why-even-let-users-set-their-own-passwords.md')
| -rw-r--r-- | content/entry/re-why-even-let-users-set-their-own-passwords.md | 8 |
1 files changed, 4 insertions, 4 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 06e53fb..39c8da9 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 @@ -20,7 +20,7 @@ Second, these email tokens actually give the attacker several more avenues to ga * 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 +* [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 @@ -60,11 +60,11 @@ I agree. I also think it would be a good idea to include a notice telling the us 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://www.wikipedia.org/wiki/Hash_function "Hash Function") rather than using a relatively expensive [key derivation function](https://www.wikipedia.org/wiki/Key_derivation_function "Key Derivation Function") that needs its iteration count constantly updated and requires storing a [salt](https://www.wikipedia.org/wiki/Salt_%28cryptography%29 "Cryptographic Salt"). [Rainbow tables](https://www.wikipedia.org/wiki/Rainbow_table "Rainbow Table") and password cracking software would be so useless that no sane attacker would even attempt it. +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://www.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. +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”." @@ -89,7 +89,7 @@ I think the reason websites' login systems often seem confused about what they'r * 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://www.wikipedia.org/wiki/WebAuthn) is a good idea, but the tech-illiterate user will get locked out when their [FIDO](https://www.wikipedia.org/wiki/FIDO_Alliance) device breaks or gets lost or they buy a new computer with a different [TPM](https://www.wikipedia.org/wiki/Trusted_Platform_Module). +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. |