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

311–320 of 392 posts

Re: Why even let users set their own passwords?

#311

Post by seabass-labrax »

ghusto wrote: post #234
seabass-labrax wrote: post #85

Earlier quoted context omitted.

Indeed, but you still need a Personal Access Token to integrate pull requests and issues with your Git client. GitHub doesn't support SSH authentication in those cases.

By git client, do you mean something other than git? Something like a CI system? Even there you can use an SSH key?

I should have clarified; sorry. I was referring to how some editors and IDEs can interact with git repositories. For instance, if I was editing a file that had uncommitted changes, it might display that text in a different colour. Interaction with GitHub might be in the form of browsing pull requests within the IDE.

This is what I do with Emacs using a package called Magit[1]; VS Code comes with something similar.

[1]: https://magit.vc/

Re: Why even let users set their own passwords?

#312

Post by tomjen3 »

anderspitman wrote: post #258
tomjen3 wrote: post #186

Earlier quoted context omitted.

For one thing, I now have to be logged in on my mail on the device I am using, and that means if the device is unsafe, I am exposing far more of a risk that way. It also forces me to look at my email inbox, which can be a pretty annoying thing if I am trying to relax and now see some email with bad news - requireing me to break the flow again. Most important however: it is simply wrong and not needed. The flow has be…

> For one thing, I now have to be logged in on my mail on the device I am using, and that means if the device is unsafe, I am exposing far more of a risk that way What's preventing you from getting the email code from another device?

Thats assuming I have it on me. I might not, or I might need to dig it out of a bag.

Re: Why even let users set their own passwords?

#313

Post by BenjiWiebe »

teddyh wrote: post #289

There are some who claim that people will demand a way to set their own passwords. This has not been my experience. At work, we have been setting random secure passwords for e-mail and web site customers for more than 10 years (the practice was in place before I started, so I can’t give an exact time). Very occasionally, a customer asks to change a password and give them a new one, which we gladly do.

Just so your idea of random and secure isn't flawed...

Some websites think they enforce secure passwords, but don't seem to understand that a random password will occasionally have duplicate characters, or might include symbols other than @!#$, or might be longer then 10 characters.

Re: Why even let users set their own passwords?

#314

Post by wolrah »

londons_explore wrote: post #215
andai wrote: post #188

Earlier quoted context omitted.

>50 MB excludes most messaging apps The entirety of TempleOS (including dozens of programs and multimedia games) is 2MB.

This isn't just the limit for css/js... It's the limit for user data too. Ie. if you share some videos with a PWA app, then all the videos have to fit inside 50MB unless you want to fetch them from a server each time you play them. Or consider a PWA music player - 50MB of music is all you can play offline. Or a photo editor - 50MB is the limit for all your saved files unless you want to save them to a cloud server.

> Or consider a PWA music player - 50MB of music is all you can play offline.

> Or a photo editor - 50MB is the limit for all your saved files unless you want to save them to a cloud server.

Why should either of these be saving files in an app-specific private datastore? Music, photos, videos, etc. should be in the standard system locations. The app's data storage should be solely used for settings, cache, and other internal data only useful to the app.

I'm not familiar with PWAs but if they can't access system storage then I don't think they're a useful choice for a music player or photo editor.

Re: Why even let users set their own passwords?

#315

Post by nullc »

kmeisthax wrote: post #197
londons_explore wrote: post #36

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…

This is what HTTP auth headers are for, but the UX for using header authentication on modern browsers is utter garbage. There's no way to present a themed login form, no way to log the user out at all , and all sorts of weird papercut bugs[0] in between. [0] My favorite: opening DevTools triggers a second credential prompt because the DevTools session wants to download some mapfiles or something. No infrastructure ex…

> This is what HTTP auth headers are for, but the UX for using header authentication on modern browsers is utter garbage.

I had assumed the cause was something like this: Product management people want functionality which is fundamentally incompatible with security-- like complete control of the appearance and behavior of the login form (which can't be squared with impersonation attacks). Security people substantially control the https auth experience, and say NO. Product management people say fine, and just don't use the secure login functionality.

Everyone is happy: PMs get the security dumpster fire they asked for, Security people keep their perfect ice castle and can complain that all breaches are the fault of the PMs doing the wrong stuff. Except the users, of course, who get a needlessly insecure experience because there are many improvements to the http auth process that don't substantially compromise security.

Re: Why even let users set their own passwords?

#316

Post by nullc »

hm?

We let users set their own passwords because users are unable to remember secure passwords, which would create a lot of work for people running the service (and the user as well), even vulnerabilities because we'd be habituated to recovering lost passwords.

When the user can set their password they will set an insecure one that they can remember, eliminating most of the password reset work. Then when the user is compromised it's their fault. This compromise works because most users aren't particularly vulnerable-- no one is trying, or no one cares if they are compromised.

Why don't we just rely on the recovery security? well Mozilla's persona thing pretty much did.

Re: Why even let users set their own passwords?

#317

Post by [deleted] »

londons_explore wrote: post #36
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…

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…

[deleted]

Re: Why even let users set their own passwords?

#318

Post by Pesthuf »

rjh29 wrote: post #278
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…

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.

Imagine if these people made posts like "I edited user32.dll to dummy out random functions I deem unnecessary like RegisterClass or CreateWindowEx and now nothing works! This is proof that Windows is broken!"

It will forever be a mystery for me why people deliberately make their browsers work in ways that contradict the standards the web is built on and then manage to find blame in others when stuff doesn't work. It's already difficult enough to support all major browsers when their interpretations of the standards differ very slightly.

Re: Why even let users set their own passwords?

#319

Post by e_y_ »

sublinear wrote: post #110
hkt wrote: post #91

Earlier quoted context omitted.

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.

The UX for client certificates is horrible and practically an afterthought, so it's no surprise.

Re: Why even let users set their own passwords?

#320

Post by anderspitman »

Eisenstein wrote: post #279
anderspitman wrote: post #269

Earlier quoted context omitted.

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.

You're ascribing a ton of ill will here, and I hope you'll give me a little more grace, but on the other hand maybe there is some truth to your words. I'll see if I can communicate more clearly and authentically in the future. Thanks for the opportunity to introspect.
Post reply on HN