Why even let users set their own passwords? • Hacker News Board

Re: Why even let users set their own passwords?

#11

Post by raesene9 » Sat, Jul 22, 2023, 2:49 PM UTC

The advice on passwords very much depends on the level of control that a system operator has on its userbase, and the threat model of the site.

In an end-user B2C style website, whilst passwords (and MFA) etc are needed for Authentication, the operator has limited control over users and if you annoy your users too much, with things like mandatory system generated "high entropy" passwords, they'll stop using your site (assuming there are other options available).

In a corporate style service it's different as the operator can mandate things like the use of MFA and the use of password managers.

I've seen systems that did the "system controlled password" thing in the past and, if done incorrectly, it just leads to users writing their passwords down somewhere (e.g. sticking them to a post-it note under their keyboards).

Re: Why even let users set their own passwords?

#12

Post by belinder » Sat, Jul 22, 2023, 2:49 PM UTC

If you want api keys to replace passwords then users need a built in mechanism on their device that stores it, since the majority of people are not going to be able to or want to copy some long obscure token and store it somewhere for later access. Some devices already have password managers and similar mechanisms built in, but it needs to be universally implemented and accepted before you could do something like this. Then there's still the question on do you share the api keys across devices?

Re: Why even let users set their own passwords?

#13

Post by paulryanrogers » Sat, Jul 22, 2023, 2:50 PM UTC

paddw wrote: post #2

Because for the average user it is still significantly easier to download some app to use in combination with a password they have a mnemonic for rather than having to figure out their own system for storing and retrieving long tokens in a reliable way. Also, most users are not obsessively clearing out their cache, so device recognition based password flows work seamlessly a lot of the time.

Average users are also unlikely to enter passwords often enough for them to remember or develop mnemonics. For them forgot password emails are the defacto login method.

Re: Why even let users set their own passwords?

#14

Post by iambateman » Sat, Jul 22, 2023, 2:51 PM UTC

Login PIN by email is a much better pattern along the same lines. Forcing a specific, impossible to remember string on the user is weirdly hostile.

If you want to avoid a password, just email the user a PIN every time they need to login. This works great for apps which don’t need high security.

Re: Why even let users set their own passwords?

#15

Post by kstrauser » Sat, Jul 22, 2023, 2:52 PM UTC

CrampusDestrus wrote: post #3

Here's why: the world is not able bodied Americans, so let us decide what password is best for us through our input methods

That’s an interesting POV. Thanks!

Re: Why even let users set their own passwords?

#16

Post by 38 » Sat, Jul 22, 2023, 2:52 PM UTC

> 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.

GitHub does this now. you cannot push with your normal password, only a Personal Access Token. I am fine with this, but perhaps the process of setting and getting the token could be streamlined. Currently, you have to:

1. click profile

2. click settings

3. click developer settings (the last item of 24 items)

4. click personal access tokens (again the last item in the list)

5. click tokens classic (again the last item)

6. click generate new token

7. click generate new token (classic)

8. enter password

9. click confirm

10. enter note

11. choose expiration

12. choose scope

13. click generate token

thats just way, way too many steps for the average user.

Re: Why even let users set their own passwords?

#17

Post by nvahalik » Sat, Jul 22, 2023, 2:54 PM UTC

laputan_machine wrote: post #10

There is an overwhelming amount of superfluous text in this article. The author's solution: > 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…

He also claims that TOTP storage in the password manager is useless. It's only useless if the entire password manager is compromised. If your attack vector is a keystroke logger, or compromise of a single password via a dump, or even someone having written down the password... storing the TOTP is still effective.

Re: Why even let users set their own passwords?

#18

Post by unboxingelf » Sat, Jul 22, 2023, 2:54 PM UTC

this is effectively how nostr works. you generate a public/private keypair. the keys are bech32 encoded.

https://github.com/nostr-protocol/nips/blob/master/19.md

Re: Why even let users set their own passwords?

#19

Post by lolinder » Sat, Jul 22, 2023, 2:54 PM UTC

> 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.

The phasing out of third-party cookies has nothing to do with the "remember this device" functionality, because those are almost always powered by first-party cookies, which are not being phased out.

The author has configured their browser to throw away cookies when the last tab closes, and that's their prerogative, but anyone who is savvy enough to configure that setting is also savvy enough to understand that that will break "remember this device". For everyone else, that phrasing is a perfectly reasonable abstraction on what is actually happening.

Re: Why even let users set their own passwords?

#20

Post by khromov » Sat, Jul 22, 2023, 2:54 PM UTC

Great post, I came to much the same conclusion when building my app - a secure token is generated on account creation and users are encouraged to save it in case the need to restore their account. I blogged about the implementation below together with how the UI looks (under the "Authentication" heading): https://khromov.se/building-a-privacy-friendly-self-hosted-a...