Live data from Hacker News

Why even let users set their own passwords?

devever.net

51–60 of 392 posts

Re: Why even let users set their own passwords?

#51

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

And then the credentials get stolen through phishing

Re: Why even let users set their own passwords?

#52

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…

A randomly generated password is not incompatible with the notebook approach...

Re: Why even let users set their own passwords?

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

Re: Why even let users set their own passwords?

#54

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

I saw this pattern done on a forum. You just provided your email, and it would set a super-long-lived cookie. There was a button for "recreate my cookie" which sent you an email - like a password reset function without a password.

It was surprising the first time I used it but now I wish everything that didn't handle cash worked that way.

Re: Why even let users set their own passwords?

#55
post #22

Earlier quoted context omitted.

[flagged]

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.

Re: Why even let users set their own passwords?

#56

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.

Re: Why even let users set their own passwords?

#57

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…

A randomly generated password is not incompatible with the notebook approach...

It is when they are all a variant of each other. I can't imagine him successfully writing down a bunch of none alphanumeric characters and not giving up.

Re: Why even let users set their own passwords?

#58
> This step is commonly something like “enter the code in an email we just sent” when trying to login.

Because email is insecure, and there is zero guarantee that your login email will arrive before the token expires. Your token does expire, right?

> We are literally living through the gradual phase-out of third-party cookie.

Yes, and a "remember this device" uses a first-party cookie, so it isn't affected.

> My own browser erases all cookies from an origin immediately after the last tab from that origin is closed

So you are intentionally breaking the web and complaining that things are cumbersome? Gee, I wonder why.

> [..] yet that same website is happy to let me authenticate using an API key for API access as a single authentication step. No “2FA” here.

Yes, because that API key is often used to sign the request, contains enough entropy to make guessing impossible, and because the URL is hardcoded in the app phishing is impossible.

> guaranteed use of a high-entropy secret obviates the need for additional authentication

No, it does not. See: phishing.

Forcing the use of website-generated passwords is cute, but doing basic entropy checks on a user-provided password pretty much solves the issue anyways. Why bother alienating a significant fraction of your user base?

Authentication is pretty much a solved problem. Use a password locker encrypted using a single remembered key for the "something you know" part, and use a physical Webauthn token for the "something you have" part. Stop trying to reinvent the wheel, it'll only end up annoying your users.

Re: Why even let users set their own passwords?

#59
Honestly, unless you're a major cloud/OS provider like Google/FB/MS/Apple, you shouldn't be managing passwords at all. Let the pros do that. You just use an authentication standard via a 3rd party.

If you aren't big enough to maintain your own operating system and web browser, you shouldn't be storing passwords.

Re: Why even let users set their own passwords?

#60

There is an overwhelming amount of superfluous text in this article. The author's solution: > Rather than allowing a user to set their own password, passwords can be issued in exactly the same way as API keys are now: a high-entropy password is randomly generated by the issuing website, and the user is shown the password once only and asked to record it. If the password is lost, a new password must be generated using…

He also claims that TOTP storage in the password manager is useless. It's only useless if the entire password manager is compromised. If your attack vector is a keystroke logger, or compromise of a single password via a dump, or even someone having written down the password... storing the TOTP is still effective.

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.

Post reply on HN