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

201–210 of 392 posts

Re: Why even let users set their own passwords?

#201

Post by hartator »

> There's not really a good reason for a user to be able to set their own password unless they want to set their password to something lower in entropy to make it memorable, or reuse it between sites, both of which are deviations from the “best practice” password safe usage model.

Yeah, but at the same time if you keep loosing access to your accounts because you can’t remember your password, you are just 1FA with your email or phone number. Might as well then skip passwords entirely and use sign in via phone or email.

Re: Why even let users set their own passwords?

#202

Post by ec109685 »

arnarbi wrote: post #157
skrebbel wrote: post #30

Earlier quoted context omitted.

This is basically what passkeys are, right? Except the autogenerated password isn't even shown to the user, just stored immediately in the user’s password manager. (I recognize that it’s a bit more involved, eg if i get it right, passkeys add some public key encryption to the mix to avoid sending the “password” over the wire needlessly often etc, but those are just icing on the cake as far as I’m concerned)

There isn’t encryption nor a generated password involved with passkeys. Rather, your device generates a private key and stores it in your password manager - and only the public key is sent to the server. When you log in later, the server uses an API to give your client a random unique challenge (just some bytes), you unlock and approve and the pwm signs some stuff including the challenge and sends the signature back.…

Important to emphasize that passkeys are phishing resistant. Unlike passwords that allow you to copy and paste them to a website (hmm, auto complete isn’t working on this broken website, I can just go find it and paste it in — boom phished).

Re: Why even let users set their own passwords?

#203

Post by hinkley »

axelthegerman wrote: post #196
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…

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.

Re: Why even let users set their own passwords?

#204

Post by ec109685 »

crote wrote: post #58

> This step is commonly something like “enter the code in an email we just sent” when trying to login. Because email is insecure, and there is zero guarantee that your login email will arrive before the token expires. Your token does expire, right? > We are literally living through the gradual phase-out of third-party cookie. Yes, and a "remember this device" uses a first-party cookie, so it isn't affected. > My own…

The idea that email isn’t secure but is a key link in the registration and password reset flow always strikes me as odd.

Passkeys can’t come soon enough, and email providers better make sure they are never compromised.

Re: Why even let users set their own passwords?

#205

Post by Eisenstein »

anderspitman wrote: post #144
samwillis wrote: post #130

Earlier quoted context omitted.

Is the cost of lung cancer lower than smoking? Some people will just never change a behaviour.

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.

Re: Why even let users set their own passwords?

#206

Post by xcxcx »

hkt wrote: post #119
xcxcx wrote: post #34

Earlier quoted context omitted.

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.

Some games are zero sum and some aren't. Everyone is more secure if a large bank replaces 2FA over unencrypted SMS, even though some may be inconvenienced.

Leveling down on everyone's security in exchange for usability for a segment of the population is not a realistic long-term strategy.

Re: Why even let users set their own passwords?

#207

Post by novok »

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…

Many websites and apps can do this, but explicitly do not in the interest of 'security' and 'anti-fraud'. Discord is a pretty bad offender of this.

Re: Why even let users set their own passwords?

#208

Post by tomsmeding »

troupo wrote: post #180
tomsmeding wrote: post #146

Earlier quoted context omitted.

I am not at all claiming that all people above a certain age have difficulty with these things! Though it is usually people above, say, 40 who feel this way — and this is not a negative thing: it may well be just because they remember that a different way existed. I.e. most people with tech difficulties are older, but many older people have no tech difficulties. Though you are also correct that dealing with "technolo…

> Though it is usually people above, say, 40 who feel this way and immediately you write this: > Though you are also correct that dealing with "technology" today requires a certain level of pain tolerance. Good UX exists but is rare So it's not just 40+ year olds who feel this way

The first was about having difficulty, the second about not liking it. Again, the (fuzzy, approximate) implication goes only one way: having difficulty breeds dislike, but dislike does not imply difficulty.

EDIT: you are correct I didn't word my original message correctly. Perhaps you have a point.

Re: Why even let users set their own passwords?

#209

Post by Drew_ »

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…

> how can it know it’s doing that for me and not for someone claiming to be me?

By emailing you a OTP :)

Re: Why even let users set their own passwords?

#210

Post by superkuh »

jdthedisciple wrote: post #107
H8crilA wrote: post #76

Earlier quoted context omitted.

I don't understand your point. Do you know that major tech companies saw a near 100% reduction of successful phishing attacks after adding yubikeys? The population there is hardly uneducated, yet they still had quite a few break-ins. Some of the companies have also nearly removed passwords, changing the minimum length requirement to something like 5 lowercase characters. They still experience a near zero, or zero, ph…

Sure, you could even reduce phishing attack success rates to nearly 0% by having users authenticate with a sample of their DNA. Does that mean it's a great idea? What about losing the yubikey? In any case it's a different matter when it comes to high stake scenarios, in which case I don't mind something slightly more sophisticated. But not as the default for everything.

>having users authenticate with a sample of their DNA.

I know it's not your point and I agree with everything you're saying in this thread 100%, but DNA based login would be a username, not a password. Like all biometrics. And it'd have a really bad false positive rate if you're just doing restriction enzyme cut location tests like lots of "police work". A full exome scan ~$300-500/per might do it.

Post reply on HN