Live data from Hacker News

Why even let users set their own passwords?

devever.net

281–290 of 392 posts

Re: Why even let users set their own passwords?

#281
I've often been struck by the fact that often login via password requires 2FA but password reset doesn't (unless of course it works via email that itself requires 2FA to log into). At least some authentication systems now never bother with persistent passwords at all and simply rely on you providing a code sent in each login to your email (or occasionally still via SMS - though that's rapidly falling out of favour, at least partly because in many countries SIM-swapping a significant problem, though the bigger problem I've observed is potential delays of several minutes for codes to arrive). But I certainly wouldn't want that for systems I have to log in into multiple times a day - a combination of browser-auto-filled password, plus use of basic browser fingerprinting techniques to avoid having to require 2FA every time seems to work okay though it seems ridiculous to me that just wanting to reply to a group chat message would require the same level of verification as downloading source/documentation etc.

A compromise between allowing users full control over their passwords and none at all would be generating a list of permitted alternatives and having them pick one. What I'd then like to see is that early on you are required to supply it quite frequently, giving you a chance to commit it to memory, but then allow having the browser store it or session cookies with longer lifetimes be used. But I've yet to come across a login system where ensuring the user learns their password and doesn't forget it was a priority at all.

Re: Why even let users set their own passwords?

#282

> 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 thought "remember this device" more typically worked via a combination of browser fingerprinting (which can be pretty sophisticated, e.g. even relying on rendering behaviours) and local storage, which may or may not involve cookies.

Re: Why even let users set their own passwords?

#283

I've said it before and I'll say it again (and yes let it rain downvotes): I don't understand this whole discussion and maligning of passwords. You cannot save all people. Some fixed %-age of people will always become victims - either by choosing a terrible password or by being shot in the foot by some terribly complex 5FA device-based passphrase scheme that attempts to protect them but ends up betraying the user onc…

Based. It's trivially easy to generate passwords with 128 bits of entropy and have them managed by a password manager. Until the password manager gets hacked. Well, tough shit. If your primary device gets hacked, the hacker just has to wait until the next time you log in with the bullshit gazillion factor authentication. And it always collapses to 1FA for the lost password recovery process, which you're gonna have to…

> Until the password manager gets hacked. Well, tough shit. If your primary device gets hacked, the hacker just has to wait until the next time you log in with the bullshit gazillion factor authentication.

Can you elaborate? This scenario assumes that a) the primary device is the only 2FA option b) there is no one-time codes and c) the attacker persistently waits until a 2FA request comes through then somehow hijacks it with their own connection request?

Re: Why even let users set their own passwords?

#284
post #193
post #188

Earlier quoted context omitted.

>50 MB excludes most messaging apps The entirety of TempleOS (including dozens of programs and multimedia games) is 2MB.

At 640x480 (for the whole screen) and 16-bit color

Hey, TempleOS is simply using the resolution God requires.

Re: Why even let users set their own passwords?

#285
post #283

Earlier quoted context omitted.

Based. It's trivially easy to generate passwords with 128 bits of entropy and have them managed by a password manager. Until the password manager gets hacked. Well, tough shit. If your primary device gets hacked, the hacker just has to wait until the next time you log in with the bullshit gazillion factor authentication. And it always collapses to 1FA for the lost password recovery process, which you're gonna have to…

> Until the password manager gets hacked. Well, tough shit. If your primary device gets hacked, the hacker just has to wait until the next time you log in with the bullshit gazillion factor authentication. Can you elaborate? This scenario assumes that a) the primary device is the only 2FA option b) there is no one-time codes and c) the attacker persistently waits until a 2FA request comes through then somehow hijacks…

Nah, he just hijacks your session directly.

Re: Why even let users set their own passwords?

#286

Earlier quoted context omitted.

Password managers could take over and manage cookie storage/retrieval. Or browsers could treat cookies more like passwords and have a user-controllable flow on each new session: "Here's this site's cookies from your last session, do you want to place these back in the browser storage?" The fundamental issue is that browser cookies and password managers have an overlap in their usage domain.

Firefox remembers my passwords for me already. Why would I need an extra tool to do it? And so does Android.

not all of my passwords are for browser-based services, not all of my secrets are passwords, and I have several devices with different operating systems.

(eg, my password manager includes github recovery tokens, ssh keys and passphrases, recovery questions, my tax and health service identifiers, wifi passwords and the admin passwords)

Re: Why even let users set their own passwords?

#287

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

That basically sounds like what yubikey’s and the like try to do.

Re: Why even let users set their own passwords?

#288
post #44

Earlier quoted context omitted.

Honestly that feels like what apps are. One of the most compelling reasons to install an iOS app for something like an online bank is so that I won't have to worry about my cookies expiring and forcing me to login again.

My banking app makes me log in every time. I prefer that, but I didn't realize some apps don't do that?

Most of mine do too so I don’t use them.

Either I use a short, easy to type password for my banking so I can log in all the time, or I use a long one and use a password manager to fill it for me and we’re basically back to “use the phone’s biometric authentication” with extra steps.

There’s already a strong, secure option for authenticating the user on a mobile device… I wish everyone would use it instead of trying to use the crap option we’re using elsewhere, especially since passwords are a pain on a tiny touchscreen keyboard.

Re: Why even let users set their own passwords?

#289
There are some who claim that people will demand a way to set their own passwords. This has not been my experience. At work, we have been setting random secure passwords for e-mail and web site customers for more than 10 years (the practice was in place before I started, so I can’t give an exact time). Very occasionally, a customer asks to change a password and give them a new one, which we gladly do.

Re: Why even let users set their own passwords?

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

It seems to me like the user you're replying to is well aware of how web devs attempt to identify unique devices (browser cookies.) They're saying that the manner that this is implemented leads to poor user experiences due to the faulty assumption that just because a cookie doesn't exist in the client browser, that the device is in fact unique to previously used devices. Which I don't see how your comment actually addresses. I tend to agree with the other user. Making healthy security conscious decisions like low TTLs on local cookie storage (such as cookie purge on browser/tab close) feels unrewarded when the site enforces additional security gates on login. The point is: unique login devices may have been a good idea, but in practice the design of the web does not make them an ideal candidate for bolstering user security. Maybe someday passkeys solves the unique device problem sufficiently such that faulty assumption methods like browser cookie storage cease to be commonplace.
Post reply on HN