Live data from Hacker News

Why even let users set their own passwords?

devever.net

241–250 of 392 posts

Re: Why even let users set their own passwords?

#241

Earlier quoted context omitted.

How about local storage? Only downside is that this data isn't sent automatically on ever request (unlike cookies). It would be possible though to send this secret from local storage via a separate request and receive a session cookie that then let's you be logged in automatically

Maybe shared local storage should be a browser standard. Let me keep track of my own data, but also share it with my tablet and phone by clicking a bunch of buttons.

Even better: shared storage where every website has access to the same storage data.

Log in once, on one website, then be logged in on all websites forever.

Re: Why even let users set their own passwords?

#242
post #91

Earlier quoted context omitted.

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.

> What you're looking for is client certificates. I agree with this, but... > users are too stupid to use them they are. Key management is not trivial.

It's a myth, they are not. They are uneducated and lazy¹, not stupid.

Save for minorities with genuine learning disorders, people can learn how to click/tap a bunch of buttons in a sequence. They aren't running a PKI (that's on platform/browser vendor), they are just picking an identity from the list after all. They learn how to click the right buttons all the time, as UI designers' managers decide it's time for a new bonus and swing things around with a "new graphic language".

Basic certificate management (from end-user perspective) is not harder than password management. Passkeys are conceptually the exact same thing² as TLS client certificates, just without a purposefully neglected UI and a DIY attitude³ (TLS is supported by nearly anything, barely anything knows about WebAuthn JS shenanigans).

1) Not in a bad way. "Lazy" as in "lazy evaluation", not "lazy ass". Maybe there's a better word for this.

2) Save for some technical details, both are essentially keypair management.

3) There is almost no UI, it's just an API then all the visual bits are left out as an exercise to individual app designers (partially on platform/browser developers, partially on website developers). Browser vendors just hated those areas because they weren't deemed cool and fancy ([un]like some JS framework of the day) and shoved them under the rug as deep as they could. And unlike TLS, there is no standard how to pass data around, everyone invents their own `POST /login/webauthn` semantics.

Re: Why even let users set their own passwords?

#243
post #101

Earlier quoted context omitted.

Keylogger would still get the TOTP code. Dump would include the TOTP secret. Why write only the password down if you still need password manager for the TOTP code? I think I mostly agree TOTP in password manager is useless, but it's not worse than not having TOTP at all so it's whatever.

A TOTP code must be marked as “used” immediately after processing it, so an attacker using a keylogger would have only a few seconds at most to use the code, assuming the user typed the code from the password manager instead of copy/paste. The protection offered for TOTP in a password manager is from people who reuse the same password on multiple sites and some other site gets hacked. In that case, the attacker would…

you missed the attack. a keylogger doesn’t capture the TOTP (and fully synchronous 0-reuse TOTP isn’t possible on global scale, instead you catch it in audit) a keylogger captures the master password to the pwm that stores the TOTP secret.

Re: Why even let users set their own passwords?

#244
post #232

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

“Please read my rant about how this useless hair-shirt I wear to clear first party cookies too often breaks the web (for me)” > the web has no notion of a “device”, and this is a very intentional design choice made for privacy purposes [...] why do web developers persist in believing in this fiction of a “device”? Cookies are a core part of the web which enable the construction of stateful applications on top of a st…

[deleted]

Re: Why even let users set their own passwords?

#245
If you know what the user's password is, then you could potentially be liable for an improper access. This liability is is impossible if you have no way of knowing what that password might be, even if things you do know like 2FA codes are used with something only the user would know.

Re: Why even let users set their own passwords?

#246
post #194

Earlier quoted context omitted.

> I'm not totally comfortable with giving someone access to draw from my checking account whatever amount they claim I owe It's not comfortable, but every time you write a check you're doing exactly this.

Well a check is authorization to withdraw a specific amount (which you can verify is reasonable) after a specific time (which you can verify the funds will be good).

But the information on a check is sufficient for anyone to initiate an electronic funds transfer from your account.

Re: Why even let users set their own passwords?

#247

Earlier quoted context omitted.

> He has a notebook of passwords, that's how he works and he won't change. A notebook in a locked safe is the most secure datastore for 90 - 98% of the population - depending of how deeply you distrust NSA.

This is only true if you’re very selective about which threats you want to acknowledge. If someone breaks into my house I’d rather they just got my TV and some belongings rather than my life savings.

> If someone breaks into my house I’d rather they just got my TV and some belongings rather than my life savings

I think this is very unlikely. For one, the notebook does not contain all the information - say "Bank1 Password" - which bank is that? What's the username? What about 2FA?

Secondly, surely the whole point if a safe is that it's bolted down and hard to burgle / steal?

Re: Why even let users set their own passwords?

#249

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.

The existence of the attention economy demonstrates that your statement is blatantly false. Technology is not for people. It ought to be, but it is not. Technology exists so that the aristocracy can line their pockets and control the populace more efficiently.

Good sir, if we're going for fantasy/conspirological themes, we have to go deeper than this distasteful banality.

People and technology and aristocracy are for the memes. It's just one huge anthill where the ideas evolve, living on biological (and then technological) foundations.

Power hubs (be it aristocracy or any other form of government) is just a convenient mechanism for spreading ideas - politicians and millionaries are just superspreaders (in their respective ages, but they're losing it to the technological platforms - and of course there's a struggle). So is technology. So are people. It's all an evolutionary process - just notice how designed systems rarely win, nearly always giving to chaotic blind evolution - whatever catches more brainspace truly matters, not what works best. If the memetic winds will blow in a certain direction, LLMs may make us obsolete, but not in the way we think they would.

This comment is sponsored by "You think the moon is real?" meme. Sorry (not sorry).

Re: Why even let users set their own passwords?

#250

Earlier quoted context omitted.

This is what HTTP auth headers are for, but the UX for using header authentication on modern browsers is utter garbage. There's no way to present a themed login form, no way to log the user out at all , and all sorts of weird papercut bugs[0] in between. [0] My favorite: opening DevTools triggers a second credential prompt because the DevTools session wants to download some mapfiles or something. No infrastructure ex…

I wish there was better browser support for this but I still use it for pet projects. Last year I wrote about why I’m still using HTTP Basic Auth. https://joeldare.com/why-im-using-http-basic-auth-in-2022

Safari on iOS does not play nice with Basic Auth. No credential saving, re-promting you for credentials on each page you navigate to.

non-iOS browsers seem to handle HTTP basic auth gracefully.

Post reply on HN