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

221–230 of 392 posts

Re: Why even let users set their own passwords?

#221

Post by antonjs »

superkuh wrote: post #210
jdthedisciple wrote: post #107

Earlier quoted context omitted.

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.

And as you point out, the problem with biometrics is that once they're stolen or copied, there's no changing them. Particularly your DNA.

Re: Why even let users set their own passwords?

#222

Post by skrebbel »

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

There isn't encryption involved? I mean how can you use public and private keys without encryption?

Anyways yes, I agree otherwise. That said for all intents and purposes, the private key is a password. It’s the thing you store that gives you access to the service. That it’s not transmitted, but instead the whole public key / challenge response dance is done, is IMO sufficiently well summarized as “well, it’s a special kind of autogenerated password, which can’t be insecurely transmitted or badly stored by the service”.

If we really want people to adopt passkeys we gotta begin talking about them in terms people understand. I consider myself pretty tech savvy and it took me like 6 articles until I finally grokked that a passkey is just an autogenerated password (plus some free automatic bonus security that doesn’t affect my UX)

Re: Why even let users set their own passwords?

#223

Post by ghusto »

H8crilA wrote: post #76
jdthedisciple wrote: post #63

I've said it before and I'll say it again (and yes let it rain downvotes): I don't understand this whole discussion and maligning of passwords. You cannot save all people. Some fixed %-age of people will always become victims - either by choosing a terrible password or by being shot in the foot by some terribly complex 5FA device-based passphrase scheme that attempts to protect them but ends up betraying the user onc…

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…

> Do you know that major tech companies saw a near 100% reduction of successful phishing attacks after adding yubikeys?

His point (my emphasis):

> User picked passwords (1FA) are and will always be the single best solution that has ever existed for authentication, _considering everything from security to usability and practicality, wholistically_

So his point is that if you consider all aspects wholistically, including usability and practicality, passwords are the best solution.

I'm not saying I agree, but a 100% reduction of successful phishing attacks after introducing Yubikeys only considers security, and not the other factors.

Re: Why even let users set their own passwords?

#224

Post by freeone3000 »

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…

You can log the user out by changing the “realm” parameter, which is a freeform string and can be quite long. As well, setting realm will cause devtools to use cached credentials similar to a new tab.

“No themed login form” oh no! Anyway. (I really think that the “theming” on login and sign-up forms breaches which bits are done by the browser and which bits are not. We’ve had to kludge back support)

Re: Why even let users set their own passwords?

#225

Post by kneebonian »

highwaylights wrote: post #114
ClumsyPilot wrote: post #108

Earlier quoted context omitted.

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

This reminds me of a quote from James Mickens regarding computer security.

"Unfortunately, large swaths of the security community are fixated on avant garde horrors such as the fact that, during solar eclipses, pacemakers can be remotely controlled with a garage door opener and a Pringles can. It’s definitely unfor- tunate that Pringles cans are the gateway to an obscure set of Sith-like powers that can be used against the 0.002% of the population that has both a pacemaker and bitter enemies in the electronics hobbyist community. However, if someone is motivated enough to kill you by focusing electromagnetic energy through a Pringles can, you probably did something to deserve that. I am not saying that I want you dead, but I am saying that you may have to die so that researchers who study per-photon HMACs for pacemaker transmitters can instead work on making it easier for people to generate good passwords."

My point being if someone's motivated enough to break into your house to steal your passwords in order to steal your life savings, that's probably an outside scenario, given most B&Es are junkies looking to score enough for their next high.

Re: Why even let users set their own passwords?

#226

Post by charcircuit »

amadeuspagel wrote: post #121
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…

The max age of a cookie is a little more then a year, meaning that as long as you visit a site more then once per year, this is possible.

Coookies can live longer than a year. Making it no longer possible to make them "permanent" is a browser specific thing.

Re: Why even let users set their own passwords?

#227

Post by ghusto »

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…

> Because email is insecure, and there is zero guarantee that your login email will arrive before the token expires. Your token does expire, right?

That's a bit like saying laptops aren't secure. Well okay, laptops are not inherently secure, but my instance of laptop is secure (enough). Same with e-mail; there's nothing inherent in e-mail that would make it secure, but the way my e-mails have been set is secure (again, "enough" for practical reasons).

>> My own browser erases all cookies from an origin immediately after the last tab from that origin is closed >So you are intentionally breaking the web and complaining that things are cumbersome? Gee, I wonder why.

Clearing cookies isn't breaking the web. Some of your websites functionality may require things to happen again if I clear cookies, but a) that seems like a you problem, and b) doesn't seem broken to me.

> Yes, because that API key is often used to sign the request, contains enough entropy to make guessing impossible, and because the URL is hardcoded in the app phishing is impossible.

Not sure where you're seeing this "often", but most services I have API keys for work _exactly_ like passwords. I have to jump through a few hoops to get a working key, true, but once I have it, it's essentially a password, and used in the same way.

> Authentication is pretty much a solved problem. Use a password locker encrypted using a single remembered key for the "something you know" part, and use a physical Webauthn token for the "something you have" part. Stop trying to reinvent the wheel, it'll only end up annoying your users.

I don't feel like it's a solved problem if normal people refuse to do that. That's a solution in the same way that the advice "Everybody be nice to each other" is going to make the world a better place.

Re: Why even let users set their own passwords?

#228

Post by kortex »

radicality wrote: post #163
CyberRage wrote: post #113

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.

> the TOTP _key/seed_ is quite similar to a password

It's not though. The whole point is the secret moves once, from server to client (ignoring user exports and whatnot). Pass(word|key)s are basic authentication, and so have to be transmitted with every request. That's a huge difference in surface area. Also they are guaranteed to be high entropy, unlike user-picked passwords with no filter.

Re: Why even let users set their own passwords?

#229

Post by kortex »

crote wrote: post #79
sixstringtheory wrote: post #24

I wonder if “true multi factor” security requires exclusivity between each factor. So, you cannot “know” anything about the “thing you have”. It should be more like a yubikey that you plug into your computer and which is secure enough that you cannot get the information out of it to “know” it. That’s a little harder to do for the “thing you are” factor because we can’t design a system to use a feature we can’t unders…

100%. Storing your "2FA" TOTP tokens in your password manager is asking for trouble, in my opinion. Why put all your bags in one basket? The moment your PC gets owned your are pretty much permanently locked out of all your accounts.

I'm way more at risk of locking myself out than someone getting onto my system, getting into my password store, exporting secrets, and using them to ruin my life. Honestly it would probably make national news if someone physically burgled their digital identity.

Re: Why even let users set their own passwords?

#230

Post by DenisM »

samwillis wrote: post #173
Y-bar wrote: post #131

Earlier quoted context omitted.

I'd wager that >99% of all burglaries are looking for physical possessions which can be sold for a quick buck. Not looking for random notebooks of passwords. So locking it in a safe might not be optimal because it will be like putting a spotlight on it.

Something like 90% of burglaries are looking for car keys. That's why I keep my keys by the front door in eyesight on anyone who comes in. I have insurance, and don't want a thug wandering around my house.

Now there’s a thought. Clever.

Does it make sense to also keep some decoy items, like an old MacBook in plain sight?

Post reply on HN