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

Re: Why even let users set their own passwords?

#91

Post by hkt » Sat, Jul 22, 2023, 3:32 PM UTC

londons_explore wrote: post #36

lolinder wrote: post #19

> 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, amongs…

I kinda wish there was something like cookies, but even more persistent. Lets call them permacookies. I want to "remember my device", and have that keep me logged in forever with a permacookie. I don't even want to have a username and password. I want to create an account and be forever logged in. There would be mechanisms to backup my permacookies, or transfer them to other devices. I'd have control of which sites c…

What you're looking for is client certificates. This has existed for years but webby people think users are too stupid to use them, so we get the menagerie of half baked trash we have now instead.

Re: Why even let users set their own passwords?

#92

Post by justsomeadvice0 » Sat, Jul 22, 2023, 3:32 PM UTC

A long time ago I wrote a variant of this - the signup page would generate a token, place it in a hidden password field, submit a hidden form, and instruct the user to click the "Save password" dialog in their browser. One advantage of this was e.g. Chrome would sync the password immediately across all your devices (in some ways this was a privacy violation, although one that the user had to explicitly opt themselves into). New sessions (e.g., if you reset or lost your browser's stored passwords) still happened via email verification, though.

Today I would just use passkeys.

Re: Why even let users set their own passwords?

#93

Post by ryukoposting » Sat, Jul 22, 2023, 3:33 PM UTC

I appreciate that there is at least one other person on earth who shares my skepticism of many popular MFA implementations. A lot of them add more inconvenience than security. "We sent a code to your email" is particularly heinous.

Re: Why even let users set their own passwords?

#94

Post by seabass-labrax » Sat, Jul 22, 2023, 3:33 PM UTC

fieryskiff11 wrote: post #25

38 wrote: post #16

> 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 generat…

GitHub is a development platform, heavily related to tech though. People that are experienced enough to do git push can definitely manage API key-like passwords. This solution is not exactly suitable for any other industry, its literally a call for bankruptcy (unless you are B2B, and even with that, so many tickets, support overload...)

99% of their users, even 99.99% might be programmers, but I was involved with a project where most of the contributors were lawyers. Most of them could only use the GitHub web interface ('edit file', not even the VS Code one) to make changes, so making it easier for them to use git push would be advantageous for everyone involved.

Re: Why even let users set their own passwords?

#95

Post by two_handfuls » Sat, Jul 22, 2023, 3:33 PM UTC

lolinder wrote: post #83

two_handfuls wrote: post #74

The problem with cookies (and “remember this device”) is that the same mechanism is used for remembering things that help the user (that we are logged in) and things that harm the user (ads, tracking). Edit: I’m talking about first-party cookies.

That's why we're in the process of phasing out third-party cookies but retaining first-party cookies. It's the closest dividing line we have for "good" and "bad" cookie applications: most good cookies are first-party (there are some use cases that are unfortunately caught in the crossfire) and most bad ones are third-party. Any time you give developers access to storage on the user device for any reason, you've given…

I was talking about first-party cookies.

Third-party cookies don’t have this ambiguity, they’re unequivocally bad.

Re: Why even let users set their own passwords?

#96

Post by j5155 » Sat, Jul 22, 2023, 3:34 PM UTC

londons_explore wrote: post #86

samwillis wrote: post #47

Earlier quoted context omitted.

This is why I hope PWAs take off more. If there is an implicit "save first party cookies forever" for PWAs that have been "installed" and we make them discoverable it's a net win.

Apple will make sure PWA's aren't successful. They can't risk their control over the app ecosystem.

Are you aware that iOS supports PWAs, and recently implemented notifications for them?

Re: Why even let users set their own passwords?

#97

Post by kunalgupta » Sat, Jul 22, 2023, 3:34 PM UTC

fingerprint works, no? (e.g. “Built In Authenticators) everything else kind of silly if so

Re: Why even let users set their own passwords?

#98

Post by hkt » Sat, Jul 22, 2023, 3:34 PM UTC

hanniabu wrote: post #51

londons_explore wrote: post #36

Earlier quoted context omitted.

I kinda wish there was something like cookies, but even more persistent. Lets call them permacookies. I want to "remember my device", and have that keep me logged in forever with a permacookie. I don't even want to have a username and password. I want to create an account and be forever logged in. There would be mechanisms to backup my permacookies, or transfer them to other devices. I'd have control of which sites c…

And then the credentials get stolen through phishing

The idea with client certificates is that they'll live in a secure keychain and never leave it. The API exposed by whatever manages them will expose functions of the key (authenticate, encrypt) but not the key itself. If the implementation is decent, you'll authenticate every request, so it isn't possible for requests to be forged or credentials stolen unless you've got a vector to attack the OS's keychain.

Re: Why even let users set their own passwords?

#99

Post by _jal » Sat, Jul 22, 2023, 3:34 PM UTC

xcxcx wrote: post #34

tylerrobinson wrote: post #29

Earlier quoted context omitted.

Using economics terminology doesn’t make this insensitive opinion any more valid. Technology is for people, not the other way around.

Nobody gets to decide what's more or less sensitive. Younger generations can argue being rendered homeless due to mass housing affordability issues is also insensitive.

> Nobody gets to decide what's more or less sensitive

That's simply incorrect. Everyone gets to decide.

Re: Why even let users set their own passwords?

#100

Post by lolinder » Sat, Jul 22, 2023, 3:35 PM UTC

crote wrote: post #81

haunter wrote: post #32

I play a japanese gacha game and there is no password there for your account. If you want to login they send you a code to your email and then you use that (valid for 30 seconds). I'm not a security expert but I always liked that for some reason

The problem is that email is not guaranteed to arrive in 30 seconds. Speaking from experience, it is extremely frustrating trying to access a resource and being unable to do so because someone in the entire email chain did a transient whoopsie.

Yep. And it's often not solvable by just sending the email again: I've more than once found cases where an app's email provider is particularly slow and the tokens arrive late no matter how many times I send them.

Bonus points if each email has a new token and only the most recent one is valid, because then you're stuck trying to remember how many times you clicked the "email me" button. Is this the right token, or am I waiting for one more to come in?