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.
Why even let users set their own passwords?
281–290 of 392 posts
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…
Re: Why even let users set their own passwords?
#283I'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…
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?
#284Re: Why even let users set their own passwords?
#285Earlier 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…
Re: Why even let users set their own passwords?
#286Earlier 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.
(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…
Re: Why even let users set their own passwords?
#288Earlier 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?
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?
#289Re: Why even let users set their own passwords?
#290> 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…