Live data from Hacker News

Why even let users set their own passwords?

devever.net

271–280 of 392 posts

Re: Why even let users set their own passwords?

#271

> 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'm sure I'm missing something, but... isn't that cookies?

I think expiration fields on cookies are optional (correct me if I'm wrong), you just can't rely on them sticking around because the user might clear them (I'd have control of which sites could set permacookies for when I didn't want to be tracked too). Which is honestly desired behavior, I'm assuming you would want the ability to delete a permacookie.

Cookies can't be synced through Firefox sync (I thought they could but just checked and my bad, they can't) -- but there's nothing preventing browser sync from handling that, and Firefox sync is E2EE so it would as secure as any other transfer method. It wouldn't be too hard to build a browser extension to allow exporting them or importing them manually; cookies are just text content so they're trivial to inspect and manipulate and even manually copy and paste into new browsers through the dev tools.

As a login mechanism, having a permacookie is somewhat insecure so most sites use expiration dates. I'm sympathetic to the desire to be able to override that, but... the mechanisms most sites use are things like signed tokens with expiration dates checked serverside, so there's not much a browser can do about blocking a website from doing that. Short of using stateless key-based authentication I'm not sure how it would be technically possible to get rid of that behavior.

----

I'm being a little bit disingenuous here in the sense that... yeah I want native file access too. I understand that cookies are not the same as native file access and the controls aren't really the same. But that's a much larger conversation with much larger scope and with more implications for browser security.

But if you're talking specifically about login, it does seem like cookies are mostly doing everything you want and your bigger problem is just that websites time-out logins? And that Firefox sync doesn't currently sync them, which... an extension could handle that.

What is the non-permanent part of a cookie, is it just that user controls for clearing cookies aren't granular enough and they're too easy for the user to accidentally delete?

I guess mobile too, iOS safari will clear localstorage sometimes. That's a very real issue (and a big reason why I want native file access), but it's less of an issue for login since occasionally losing your login permacookie isn't a big deal, it's only a big deal if you lose offline serverless webapp data.

Re: Why even let users set their own passwords?

#274

Earlier quoted context omitted.

How about local storage? Only downside is that this data isn't sent automatically on ever request (unlike cookies). It would be possible though to send this secret from local storage via a separate request and receive a session cookie that then let's you be logged in automatically

Maybe shared local storage should be a browser standard. Let me keep track of my own data, but also share it with my tablet and phone by clicking a bunch of buttons.

This is circling around Native File Access, which is absolutely something the web needs and if handled correctly would be a huge improvement for user privacy and user autonomy. It would open the door for fully offline webapps with no accounts or serverside components, with much better sandboxing than native apps, and with full user control over app data using just a file browser. And it would allow for app data that could be easily shared between apps when necessary without compromising user privacy or security because the app data would just be a directory with files.

BUT... the problem is that if handled incorrectly it would be a disaster for web security, would open up tons of holes for user tracking and data theft, and would basically be a horror show. There are a dozen things that could go wrong with the spec, and all of them would be serious problems if they did go wrong.

And Chrome is heavily involved in the spec. So it's a tough position to be in to try and figure out whether it's worth advocating for. Mozilla currently considers native filesystem access to be harmful, and I don't know whether or not I agree with them. I wish Mozilla would propose an alternative spec developed entirely internally without interaction from Google.

Re: Why even let users set their own passwords?

#276

The company I work for currently gave me my password, comprised of four space-separated words, on my first day. It has no expiry and can only be changed at request or if compromised. My only gripe with this approach is that my specific password is a bit awkward to type. I tend to pick passwords at least partly based on "keyboard feel" and it's annoying that there's one word that has a lot of repetition of colocated l…

This seems an interesting approach, if sufficiently safe for most cases. What if, when creating an account and choosing a password, the app enforced very long passwords but suggested a default, random one like in your example? This would have most of the benefits of the suggestion in the article (high entropy) while still not removing the choice of the user to pick their own preferred password.

Does your company also use 2FA? I'd be curious to see if very long passwords are secure enough to not need the 2FA anymore, as most methods are annoying to the user.

Re: Why even let users set their own passwords?

#277

> 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 dont agree with you that it's the user's fault. The issue isn't understanding of remember this device feature. The issue is it's a fundamentally broken design. One, because users have multiple devices and second, the feature is crippled when employing privacy preserving behavior. I should be able to authenticate by proving access to a device such as a yubikey, as an example. Now, the site can properly remember the…

When I think 'multiple devices' I think 'multiple devices'. Yubikey is a solution for multiple computers but I don't see how something 'such as a yubikey' solves this problem for devices.

Re: Why even let users set their own passwords?

#278
post #232

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

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

Thank you for teaching me the word hair-shirt. These kind of blog posts come up often on HN and it's good to have a word to describe them.

Re: Why even let users set their own passwords?

#279

Earlier quoted context omitted.

I am not arguing for or against your position. I am using the form you just used in order to mirror how annoying doing something like that is.

Your initial intent was clear. I was simply trying to move this towards something productive. Clearly I failed

You don't seem to be 'simply' doing anything. Everything you have posted besides the first comment about phishing is some kind of dodge which uses obvious manipulation tactics, for instance saying 'I do that myself sometimes', which is a cop method for encouraging confessions, or 'you can have the last word' works to actually let you have the last word. Stop doing that.

Re: Why even let users set their own passwords?

#280

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

He's right that it's a him problem- but my bank and my HR website both have "Remember this device" placebo checkboxes that do absolutely nothing. The feature is broken way too often even on stock browsers.
Post reply on HN