Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why even let users set their own passwords?

devever.net

Post reply on HN
Print view View original

291–300 of 392 posts

Re: Why even let users set their own passwords?

#291

Post by lolinder »

starttoaster wrote: post #290
brasic wrote: post #232

Earlier quoted context omitted.

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

It seems to me like the user you're replying to is well aware of how web devs attempt to identify unique devices (browser cookies.) They're saying that the manner that this is implemented leads to poor user experiences due to the faulty assumption that just because a cookie doesn't exist in the client browser, that the device is in fact unique to previously used devices. Which I don't see how your comment actually ad…

I'm the parent commenter, but the viewpoint you're agreeing with is an extract from the article, not my perspective, as indicated by the > before the paragraph. My own comments are the subsequent two paragraphs.

In short, I entirely agree with @brasic: the article author has a nonstandard configuration (clearing cookies automatically before their expiry date) and based their entire article on the difficulties that this highly unusual and unnecessary choice has caused for them. "Hair shirt" is a great way to describe it.

> Making healthy security conscious decisions like low TTLs on local cookie storage (such as cookie purge on browser/tab close) feels unrewarded when the site enforces additional security gates on login. The point is: unique login devices may have been a good idea, but in practice the design of the web does not make them an ideal candidate for bolstering user security.

This is exactly @brasic's point, though: if a website can affirmatively identify that you've logged in from this machine before, that's a pretty good indicator that this new session is a legitimate login. We can do that through cookies, and for most users that's just fine. If you clear cookies regularly for security reasons, then you shouldn't be offended that a website asks you for extra confirmation that you are you, since that is also done for security reasons.

Clearing cookies for a domain is instructing your browser to identify itself as though it had never spoken to that server before. If you want the server to know you're still you, maybe just leave the cookies there?

Re: Why even let users set their own passwords?

#292

Post by Ferret7446 »

lolinder wrote: post #19

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

> anyone who is savvy enough to configure that setting is also savvy enough to understand that that will break "remember this device"

I don't think so. Most people who understand that that will break "remember this device" also understand that clearing cookies doesn't help much with privacy. So the people who do enable that setting generally only know that cookies == tracking and do not understand that that will break "remember this device" ("Dunning-Kruger").

Re: Why even let users set their own passwords?

#293

Post by r00fus »

sjadoinqwoeihad wrote: post #60
nvahalik wrote: post #17

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.

Keylogging + dump of password manager requires 2 different but related compromises, no?

Ultimately if someone can log keystrokes and has access to your device, it's game over.

Re: Why even let users set their own passwords?

#294

Post by r00fus »

jiveturkey wrote: post #243
orev wrote: post #101

Earlier quoted context omitted.

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…

you missed the attack. a keylogger doesn’t capture the TOTP (and fully synchronous 0-reuse TOTP isn’t possible on global scale, instead you catch it in audit) a keylogger captures the master password to the pwm that stores the TOTP secret.

But then they have to have physical access to your pwm or an export of it. If it's cloud-based, I'd have to assume there's some additional auth done for non-approved devices, or it's a bad cloud pwm.

Re: Why even let users set their own passwords?

#295

Post by lll-o-lll »

samwillis wrote: post #5

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, or two factor, it's just never going to happen.

Have you tried the “passkey” integration on Apple devices? If so, do you think your father would be able to use that?

To me, it seems such a simple UX that I can’t imagine even the most technically illiterate being unable to use it. In the Apple ecosystem, there is literally no configuration for the “password manager” it’s just integrated into the Apple Account. You’d go from a notebook of passwords to just one (the main Apple ID password, for recovery etc).

Obviously “passkey” is not available in most sites yet, but I imagine that once it is, the switch might be pretty painless for the non-tech savvy. Assuming the other device manufacturers can provide similar seamless integration.

Re: Why even let users set their own passwords?

#296

Post by ewi_ »

janalsncm wrote: post #239
orev wrote: post #158

Earlier quoted context omitted.

Please pay attention to the use of pass-PHRASE. Pass-phrases are well understood at this point as far as what they are and how to generate them securely. A key point is that they’re much longer so have plenty of entropy to resist cracking attempts.

The article is discussing the merits of letting users generate their own passwords at all. So unless you can guarantee the website will generate nice pass phrases, you’ll have to account for weird characters too.

A password manager can generate nice passphrases. Really, generating a nice and secure passphrase is no different from a nice and secure password at this point. It's all about entropy and byte mapping.

Re: Why even let users set their own passwords?

#297

Post by krupan »

jdthedisciple wrote: post #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 onc…

I kind of see where you are coming from, because it's true that every alternative to passwords that seems to be gaining traction right now is horribly complicated. Webauthn and passkeys are like the IPv6 of security upgrades. Waaaaay, way more than is needed to improve upon the security of passwords.

Now, the rest of your argument kinda sucks, sorry to say. There are things we can do to make everyone's personal information more secure. Using childhood clubhouse password "technology" is not cutting it. We can definitely do better than shared secrets that get leaked to the whole internet on the regular. We can be more secure with an easier to use UI. Yes, people will still get pwned, but less people will, the bad guys will have to work harder.

Re: Why even let users set their own passwords?

#298

Post by krupan »

CyberRage wrote: post #264
radicality wrote: post #163

Earlier quoted context omitted.

My understanding of the post was the the author means that from the point of view of “authenticate this user”, the TOTP _key/seed_ is quite similar to a password, which I would agree with. Especially if you’re storing both in your password manager like the OP.

It is not because: 1. TOTP is time based, after 30 seconds it means absolutely nothing, you cannot recreate the 'secret key' from that number 2. with TOTP everything is well-known. TOTP will usually generate a 6 digit 'secret', this makes managing it very predictable: 6 digits = 1,000,000 options(including all zeros) we can easily calculate a good security margin like: 5 attempt - 5/1,000,000 = 0.000005% chance of su…

While you are technically correct, you are missing the whole point of the blog post

Re: Why even let users set their own passwords?

#299

Post by wilg »

lll-o-lll wrote: post #295
samwillis wrote: post #5

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, or two factor, it's just never going to happen. Have you tried the “passkey” integration on Apple devices? If so, do you think your father would be able to use that? To me, it seems such a simple UX that I can’t imagine even the most technically illiterate being unable to use it. In the Apple ecosystem, there is literally no configuration for the “pas…

Yeah, exactly. The writing is on the wall for password based authentication. I think this is all going to look very different in a year or two.

Re: Why even let users set their own passwords?

#300

Post by brasic »

lolinder wrote: post #291
starttoaster wrote: post #290

Earlier quoted context omitted.

It seems to me like the user you're replying to is well aware of how web devs attempt to identify unique devices (browser cookies.) They're saying that the manner that this is implemented leads to poor user experiences due to the faulty assumption that just because a cookie doesn't exist in the client browser, that the device is in fact unique to previously used devices. Which I don't see how your comment actually ad…

I'm the parent commenter, but the viewpoint you're agreeing with is an extract from the article, not my perspective, as indicated by the > before the paragraph. My own comments are the subsequent two paragraphs. In short, I entirely agree with @brasic: the article author has a nonstandard configuration (clearing cookies automatically before their expiry date) and based their entire article on the difficulties that th…

Yep, to be clear I was agreeing with lolinder. I would have posted top level but they had already expressed almost exactly my objection to the article so I replied to avoid redundancy.
Post reply on HN