Live data from Hacker News

Why even let users set their own passwords?

devever.net

261–270 of 392 posts

Re: Why even let users set their own passwords?

#261

Earlier quoted context omitted.

I find there are generally two reasons people use analogies. The first is to make a concept easier to understand. The second is to subtly change what is being argued in order to make their position seem stronger. I did the second for years without realizing what I was doing, and still fall into the trap.

Or the third to to illustrate the argument in another context. I usually avoid analogies of HN as you are often called out on the technicalities of them. And you are right that can often damage an argument. However, I have argued that changing peoples behaviour, even when their current behaviour is bad for them, is often impossible despite all evidence, from the beginning.

> Or the third to to illustrate the argument in another context.

This is still case 1.

I actually agree with you that some people with bad security habits will never change their behavior, but do you really feel that someone using passwords in a notebook because that's what they're comfortable with is in the same class of behavior as someone addicted to nicotine?

Feel free to have the last word here. 1 on 1 HN threads more than 3 deep rarely result in productive conversation. Cheers

Re: Why even let users set their own passwords?

#262

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.

So do I for some passwords, physical security is way easier.

Re: Why even let users set their own passwords?

#263

Earlier quoted context omitted.

I find there are generally two reasons people use analogies. The first is to make a concept easier to understand. The second is to subtly change what is being argued in order to make their position seem stronger. I did the second for years without realizing what I was doing, and still fall into the trap.

I find there are generally two reasons people pick apart argument structure rather than deal with an argument's content. The first is to point out fallacies or rhetorical devices which are invalid or illogical. The second is because they realize their position is too weak to confront it directly.

Are you sure you understand what my position is? Care to strongman it?

Fwiw I think you're actually right that HN tends to spend way too much time on semantics, and I'm certainly guilty of that myself sometimes

Re: Why even let users set their own passwords?

#264

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

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 success Very predictable security margin

for passwords it's a huge unknown, it entirely depends on the user password quality

Re: Why even let users set their own passwords?

#265

Earlier quoted context omitted.

I find there are generally two reasons people pick apart argument structure rather than deal with an argument's content. The first is to point out fallacies or rhetorical devices which are invalid or illogical. The second is because they realize their position is too weak to confront it directly.

Are you sure you understand what my position is? Care to strongman it? Fwiw I think you're actually right that HN tends to spend way too much time on semantics, and I'm certainly guilty of that myself sometimes

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.

Re: Why even let users set their own passwords?

#266

Earlier quoted context omitted.

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.

Even better: shared storage where every website has access to the same storage data. Log in once, on one website, then be logged in on all websites forever.

Isn't that basically third party cookies all over again?

If you work for advertisers this sounds like a great idea. Better than eating babies.

Re: Why even let users set their own passwords?

#267

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…

It sounds almost exactly like the mechanics of a session cookie as implemented on nearly every website on earth. Exchange a password for a bearer credential that is randomly chosen and revocable. There are only so many basic ideas in security.

Re: Why even let users set their own passwords?

#268

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

Yeah I don't think he has adequately explored what happens when the website gives him a giant token to enter and then it can't be stored in a cookie. What does he think is going to happen next?

Re: Why even let users set their own passwords?

#269

Earlier quoted context omitted.

Are you sure you understand what my position is? Care to strongman it? Fwiw I think you're actually right that HN tends to spend way too much time on semantics, and I'm certainly guilty of that myself sometimes

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

Re: Why even let users set their own passwords?

#270
post #165

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…

we already do have that and needs no certificates or other complex things for the end user: https://developer.mozilla.org/en-US/docs/Web/API/Window/loca... is it secure? hell no, but it can be used.

[citation needed] on local storage being more durable than cookies.
Post reply on HN