Live data from Hacker News

Why even let users set their own passwords?

devever.net

101–110 of 392 posts

Re: Why even let users set their own passwords?

#101

Earlier quoted context omitted.

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.

A TOTP code must be marked as “used” immediately after processing it, so an attacker using a keylogger would have only a few seconds at most to use the code, assuming the user typed the code from the password manager instead of copy/paste.

The protection offered for TOTP in a password manager is from people who reuse the same password on multiple sites and some other site gets hacked. In that case, the attacker would not be able to login, regardless of having the password.

Also, once a system is so thoroughly compromised that the attacker can install a key logger or dump a password database, that system and all the user accounts are already completely compromised.

TOTP at this point is essentially a forced password that changes every 30 seconds instead of an actual additional factor, however in many cases that’s good enough.

Re: Why even let users set their own passwords?

#102
post #88

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…

> Take my father, there is no way he could use a password manager...He has a notebook of passwords Your father does use a password manager: a slow, very inconvenient one. If you could teach him to reach for ctrl-c/ctrl-v instead of a pencil, it would be easier for him.

Indeed. I have converted my mother to 1Password and it’s working great for her once she got past the initial learning curve.

Re: Why even let users set their own passwords?

#103

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…

> 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 the same process.

I don’t understand that logic. Normally, systems generate API keys and show them to a person _knowing_who_that_person_is_.

I, when I lose my password, the system can generate a new one for me even when I’m not logged in, how can it know it’s doing that for me and not for someone claiming to be me?

Re: Why even let users set their own passwords?

#104

Earlier quoted context omitted.

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.

In the keylogger case, it still makes the attack more complicated -- they need to steal your login before that code expires, so rather than passive password-harvesting it has to be an immediate attack.

Re: Why even let users set their own passwords?

#105
post #84

Earlier quoted context omitted.

This is basically what passkeys are, right? Except the autogenerated password isn't even shown to the user, just stored immediately in the user’s password manager. (I recognize that it’s a bit more involved, eg if i get it right, passkeys add some public key encryption to the mix to avoid sending the “password” over the wire needlessly often etc, but those are just icing on the cake as far as I’m concerned)

A password can be stored offline without any electronic device or even be memorized only. Passkey depends on your device.

While you can't memorize it (memorizing a fair amount of entropy would take an intelligent human quite some time), you can of course store them offline (it's just a key). Today's initial implementation on macOS restricts exporting, but that is supposed to be added according to reliable Apple devs: https://hachyderm.io/@rmondello/110329118270492669

Re: Why even let users set their own passwords?

#106

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

Might as well use client certificates at that point. Along with TFA, if we don't have users choose passwords, then just issue a client cert and have it installed in the browser, would probably require some new web standard.

Re: Why even let users set their own passwords?

#107
post #76

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…

I don't understand your point. Do you know that major tech companies saw a near 100% reduction of successful phishing attacks after adding yubikeys? The population there is hardly uneducated, yet they still had quite a few break-ins. Some of the companies have also nearly removed passwords, changing the minimum length requirement to something like 5 lowercase characters. They still experience a near zero, or zero, ph…

Sure, you could even reduce phishing attack success rates to nearly 0% by having users authenticate with a sample of their DNA.

Does that mean it's a great idea?

What about losing the yubikey?

In any case it's a different matter when it comes to high stake scenarios, in which case I don't mind something slightly more sophisticated.

But not as the default for everything.

Re: Why even let users set their own passwords?

#108

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…

> He has a notebook of passwords, that's how he works and he won't change.

A notebook in a locked safe is the most secure datastore for 90 - 98% of the population - depending of how deeply you distrust NSA.

Re: Why even let users set their own passwords?

#109
post #32

I play a japanese gacha game and there is no password there for your account. If you want to login they send you a code to your email and then you use that (valid for 30 seconds). I'm not a security expert but I always liked that for some reason

I use two services that do the same, so it is not completely uncommon. Both services don't require frequent login, though. One service is a DNS provider and the other a learning platform where the primary way of interaction doesn't require a login at their platform.

Re: Why even let users set their own passwords?

#110
post #91

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…

What you're looking for is client certificates. This has existed for years but webby people think users are too stupid to use them, so we get the menagerie of half baked trash we have now instead.

> What you're looking for is client certificates.

I agree with this, but...

> users are too stupid to use them

they are. Key management is not trivial.

Post reply on HN