> 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…
Why even let users set their own passwords?
61–70 of 392 posts
Re: Why even let users set their own passwords?
#62We probably will stop one day, but that day isn't yet for many services. There are people who would be unable to use those services if that can't set the password to either the same or a variant of one they always use. In the tech wold we often forget that there is a wide disparity in people's ability to use tech. Take my father, there is no way he could use a password manager, or two factor, it's just never going to…
[flagged]
Re: Why even let users set their own passwords?
#63I 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 once they replace their phone or it breaks or for any other mundane reason.
User picked passwords (1FA) are and will always be the single best solution that has ever existed for authentication, considering everything from security to usability and practicality, wholistically.
If I sign up for some crappy service that I'll barely even remember a week later I should be good to go setting my password to "asdf" and that's everything I need to log in.
Fuck everything else. https://news.ycombinator.com/item?id=36717356
Re: Why even let users set their own passwords?
#64Looking forward to them being replaced with passkeys.
Re: Why even let users set their own passwords?
#65We probably will stop one day, but that day isn't yet for many services. There are people who would be unable to use those services if that can't set the password to either the same or a variant of one they always use. In the tech wold we often forget that there is a wide disparity in people's ability to use tech. Take my father, there is no way he could use a password manager, or two factor, it's just never going to…
Gonna be eagerly waiting for the time when we can finally change our behavior at will, be it neural implants or nanomachines or whatever other method of direct intervention to the brain.
Re: Why even let users set their own passwords?
#66If 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 thi…
Re: Why even let users set their own passwords?
#67For a login situation with extreme rate limiting (say 3 tries a day) "high entropy" might not involve a lot of randomness. A random 8 character password handed out to a user is overkill. Two random words is overkill. Heck, a single diceware word would take 7 years to guess in that environment. For 100 years you only need something like 4 base32 characters.
This isn’t the attack vector to be concerned about. More concerning is when there’s a data breach and an attacker gains access to hashed passwords. At that point, you attack the hash not the API. This comment is an example of why I wouldn’t want any given website to choose my password.
The passwords will not be of any use on any other system. This would eliminate password reuse.
Re: Why even let users set their own passwords?
#68For a login situation with extreme rate limiting (say 3 tries a day) "high entropy" might not involve a lot of randomness. A random 8 character password handed out to a user is overkill. Two random words is overkill. Heck, a single diceware word would take 7 years to guess in that environment. For 100 years you only need something like 4 base32 characters.
That’s all fun and nice until someone decides to antagonise you and they intentionally make three failed login attempts for your username into the website every n hours, keeping you unable to sign into your account.
Re: Why even let users set their own passwords?
#69Earlier 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…
Sounds like certificates. You can use ssh this way, for example.
Re: Why even let users set their own passwords?
#70Legitimising 'Risk-Based Authentication' as a strategy is a big mistake in the software industry. It allows criminals to sit on compromised credentials, trying different combinations of accounts, user-agents and IP addresses until they get the jackpot: a website decides this time that there is 'low risk' to the login attempt, and the bad actors are in. When you make security-critical decisions with statistics (in this case, whether to permit a login attempt), you are essentially guaranteeing that there will be a certain proportion of breaches, because you set the risk threshold!
Our efforts as an industry should be in making sure that credentials are not stolen in the first place: better and more widespread encryption, phishing resistance (with UX that supports that) and low-level security audits of encryption software and hardware are just a few of the areas where research and development would be valuable.