Live data from Hacker News

Why even let users set their own passwords?

devever.net

61–70 of 392 posts

Re: Why even let users set their own passwords?

#61

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

Sounds like certificates. You can use ssh this way, for example.

Re: Why even let users set their own passwords?

#62
post #22

We 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]

Yes, the abject failure of the tech industry to create usable and secure software is the fault of...checks notes...retirees.

Re: Why even let users set their own passwords?

#63
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 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?

#64
I like this article because it forces us to recognize what secure users are really doing already. I haven't created my own password for something in ~8 years, since I started using LastPass and 1Password. I have no idea what my password is on any site, never see it, can't even type it on a keyboard reliably.

Looking forward to them being replaced with passkeys.

Re: Why even let users set their own passwords?

#65
post #53

We 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.

we have less invasive solutions available already

Re: Why even let users set their own passwords?

#66

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

Yes. Like I know people that have 100% bought-in to a single architecture -- all Google or all Apple -- who use the suggested random passwords built into the cross-platform-browsers of these platforms. But if you're not a single-platform cloud-account all the things person it's much more difficult.

Re: Why even let users set their own passwords?

#67

For 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.

That assumes the situation where the password hashes are stored in a way that is less secure than the actual data that the attacker ultimately wants access to. That must not be a very common situation.

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?

#68

For 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.

I think that most people can come up with more effective ways to annoy someone.

Re: Why even let users set their own passwords?

#69

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…

Sounds like certificates. You can use ssh this way, for example.

You can use mTLS client certificates (kept in the system key store) in browsers this way; but the UX is pretty hard to get right, and certificates nearly always have to have an expiry date to deal with the compromise-able nature of keys imported into the system key store.

Re: Why even let users set their own passwords?

#70
This article is the very embodiment of how I think about authentication! I once tried explaining to a top-brass security professional at Microsoft why mandatory, SMS-based '2FA' wouldn't be an improvement over simple passwords - they just didn't get it. I wish I could have shown them this essay.

Legitimising '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.

Post reply on HN