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

111–120 of 392 posts

Re: Why even let users set their own passwords?

#111

Post by [deleted] »

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.

[deleted]

Re: Why even let users set their own passwords?

#112

Post by ballenf »

simonw wrote: post #44
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…

Honestly that feels like what apps are. One of the most compelling reasons to install an iOS app for something like an online bank is so that I won't have to worry about my cookies expiring and forcing me to login again.

But then there are apps like Discord which log you out of the app if you don't use it for X days.

Re: Why even let users set their own passwords?

#113

Post by CyberRage »

There is one incorrect statemement that really bothered me

TOTP and passwords are not the 'similar' because TOTP is a secret generated from the 'key' and is only valid for a short time period

this make usage of that secret vastly more challenging for attackers, especially at scale.

I've seen real attacks where passwords are stolen, it is impossible to keep track of that. However for TOTP since the attacker has to login NOW, you can very easily detect anomalies of a new IP addr with many successful logins for different accounts

Or to put it differently, when you capture a password it is always valid credential but for TOTP, it requires more advanced infrastructure(automatic logins, save tokens)

and even then the token will eventually expire, with password you can generate infinite tokens

Re: Why even let users set their own passwords?

#114

Post by highwaylights »

ClumsyPilot wrote: post #108
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…

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

This is only true if you’re very selective about which threats you want to acknowledge.

If someone breaks into my house I’d rather they just got my TV and some belongings rather than my life savings.

Re: Why even let users set their own passwords?

#115

Post by Tagbert »

londons_explore wrote: post #75
simonw wrote: post #44

Earlier quoted context omitted.

Honestly that feels like what apps are. One of the most compelling reasons to install an iOS app for something like an online bank is so that I won't have to worry about my cookies expiring and forcing me to login again.

I hate the fact that if you lose your phone and restore to a new one, suddenly every app is logged out again. Like can't the login-state be part of the backup? If I was logged in when the backup was taken, I should still be logged in when restored to a new device.

On iOS many (most?) apps do store your credentials in a way that you don’t have to login if you have restored from backup or setup a new device from backup. Not all do this. Google is one annoying example that requires a fresh authentication.

Re: Why even let users set their own passwords?

#116

Post by SoftTalker »

simonw wrote: post #44
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…

Honestly that feels like what apps are. One of the most compelling reasons to install an iOS app for something like an online bank is so that I won't have to worry about my cookies expiring and forcing me to login again.

My banking app makes me log in every time. I prefer that, but I didn't realize some apps don't do that?

Re: Why even let users set their own passwords?

#117

Post by tomsmeding »

gcanyon wrote: post #88
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...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.

It would be easier for you, who (I suspect) has, like most of us here on HN, a good understanding of what happens on a computer, how to control that, how to manage their software, how to be aware of what is on the foreground when and taking input when. How to recognise various applications and seeing the difference between materially different ones that try to look the same.

Your notebook will look markedly different from a website that tries to imitate your notebook. Your password manager will only look markedly different from a website imitating your password manager if you have a certain level of awareness and acuity of what happens on-screen and what it means. I think GP's father doesn't have that awareness, and never will, by choice. They choose to spend their energy elsewhere.

Younger generations had no choice and will have spent that energy already by the time they're 12 years old, and have these problems less.

Re: Why even let users set their own passwords?

#118

Post by lolinder »

two_handfuls wrote: post #95
lolinder wrote: post #83

Earlier quoted context omitted.

That's why we're in the process of phasing out third-party cookies but retaining first-party cookies. It's the closest dividing line we have for "good" and "bad" cookie applications: most good cookies are first-party (there are some use cases that are unfortunately caught in the crossfire) and most bad ones are third-party. Any time you give developers access to storage on the user device for any reason, you've given…

I was talking about first-party cookies. Third-party cookies don’t have this ambiguity, they’re unequivocally bad.

Ah. Well, as I noted, it's not a problem with the design of cookies, it would be a problem with any storage mechanism that HTTP could possibly support.

We want apps to be able to store session IDs so that I don't have to send my username/password with every single HTTP request. But as soon as I've given you permission to remember my session, you can use that to start tracking my movements on your site. There's no way around that.

The only thing we could do is add a layer on top that prevents most sites from using cookies at all—make cookies a permission similar to camera and screen sharing. But first-party cookies aren't easy to use for abusive purposes and (as we all found out post-GDPR) popup fatigue is real, so I'm personally okay leaving them as is by default. Anyone who isn't comfortable with them can easily install extensions that implement more complex behaviors.

Re: Why even let users set their own passwords?

#119

Post by hkt »

xcxcx wrote: post #34
tylerrobinson wrote: post #29

Earlier quoted context omitted.

Using economics terminology doesn’t make this insensitive opinion any more valid. Technology is for people, not the other way around.

Nobody gets to decide what's more or less sensitive. Younger generations can argue being rendered homeless due to mass housing affordability issues is also insensitive.

It is incredibly useful to powerful people to keep at this generational war narrative, as it keeps people who might otherwise work together from doing so with an aim of crushing the power of the wealthy.

The fact is, anti-human attitudes to both housing and technology are harmful everywhere. Nobody has to "win" at the other side's expense here.

Re: Why even let users set their own passwords?

#120

Post by seabass-labrax »

razorfen wrote: post #77
seabass-labrax wrote: post #70

This article is the very embodiment of how I think about authentication! I once tried explaining to a top-brass security professional at Microsoft why mandatory, SMS-based '2FA' wouldn't be an improvement over simple passwords - they just didn't get it. I wish I could have shown them this essay. Legitimising 'Risk-Based Authentication' as a strategy is a big mistake in the software industry. It allows criminals to si…

> phishing resistance (with UX that supports that) and low-level security audits of encryption software and hardware Pardon my ignorance, but isn’t this saying “we can’t rely on reducing the likelihood of breaches, we should focus on reducing the likelihood of breaches”? Your recommendations are no more deterministic than the methods you eschew.

True, but "user secrets stolen, game over" is a much more healthy starting point than "user secrets stolen, well, maybe we can let criminals use only 10% of them by making login attempts more difficult". The latter means you can say "we reduced malicious logins by 90%" when what you are really doing is reducing all unusual logins by 90%. It's true that security audits don't guarantee success, but that percentage likelihood of security improvement comes at no cost to usability.
Post reply on HN