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

231–240 of 392 posts

Re: Why even let users set their own passwords?

#231

Post by ghusto »

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.

2FA protects two different attacks: 1) Hacker obtaining your password (through phishing, compromise of third party, etc.) 2) _You_ actually being compromised yourself somehow.

It is still effective for the first protection if you store your codes in your password manager, but less for the second. I say less, and not completely, because if your machine is compromised, gaining access to your phone too is only a matter of time. Of course this can be mitigated why proper hardware tokens, but most people aren't using those.

Re: Why even let users set their own passwords?

#232

Post by brasic »

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…

“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 stateless protocol. “Remembered device” is usually just an extra cookie set on login, or a row in a backend database. It’s no more fictional than the web itself, which is after all just a series of electrical impulses over wires.

Whether a device (however you build that abstraction) has previously logged in is a high-signal data point that meaningfully increases account security at login time and all serious web security teams use it to protect their users.

Re: Why even let users set their own passwords?

#233

Post by bobbylarrybobby »

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…

Passkeys?

Re: Why even let users set their own passwords?

#234

Post by ghusto »

seabass-labrax wrote: post #85
crote wrote: post #72

Earlier quoted context omitted.

Personal Access Tokens are intended for fully automated access, such as a deployment pipeline. They are not intended for daily use, and step 4 even explicitly says "Need an API token for scripts or testing?". For regular pushing you are expected to use a SSH key, and those are far easier to add.

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?

Re: Why even let users set their own passwords?

#235

Post by codazoda »

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…

I wish there was better browser support for this but I still use it for pet projects. Last year I wrote about why I’m still using HTTP Basic Auth.

https://joeldare.com/why-im-using-http-basic-auth-in-2022

Re: Why even let users set their own passwords?

#236

Post by IshKebab »

Someone wrote: post #103
laputan_machine wrote: post #10

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

I don't understand your confusion. The generated high entropy password would be shown to you with the system knowing who you are too - because you just registered or reset your password.

Re: Why even let users set their own passwords?

#237

Post by janalsncm »

jefftk wrote: post #194
SoftTalker wrote: post #176

Earlier quoted context omitted.

Yeah and I do use autopay for some very predictable things like utilities. I'm not totally comfortable with giving someone access to draw from my checking account whatever amount they claim I owe, but realistically these days a paper check becomes an ACH payment so I figure there are non-zero chances for error that just cannot be easily avoided.

> I'm not totally comfortable with giving someone access to draw from my checking account whatever amount they claim I owe It's not comfortable, but every time you write a check you're doing exactly this.

Well a check is authorization to withdraw a specific amount (which you can verify is reasonable) after a specific time (which you can verify the funds will be good).

Re: Why even let users set their own passwords?

#238

Post by NoMoreNicksLeft »

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…

Isn't such a thing called a crypto key? And if you had such a thing, why in the hell would anyone sensible ever use browser cookie functionality to store that?

Learn to use a password manager.

Re: Why even let users set their own passwords?

#239

Post by janalsncm »

orev wrote: post #158
cubefox wrote: post #143

Earlier quoted context omitted.

It can, but it's very unlikely. Most randomly generated data doesn't have a memorable structure.

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.

Re: Why even let users set their own passwords?

#240

Post by fireflash38 »

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…

Know what my favorite part of the whole modern auth is? The most "reliable and secure" way to enter and transmit credentials is the browser. You know, that thing that has had absolutely tons of footguns with XSS problems, terrible cookie management/stealing, and generally leaving things up to websites to do auth.

They're even deprecating auth via non-browser means in newer OAuth/GNAP standards. It's like they're designing around what things are now, rather than thinking ahead as to what would be best. Like rather than website - managed auth, it be fully browser controlled (not HTML forms). Not cookies, but something prescribed by the browser (or whatever other application you might use, rather than needing to embed a browser yet again in everything).

Post reply on HN