Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why [Insert Thing Here] Is Not a Password Killer

troyhunt.com

Post reply on HN
Print view View original

241–250 of 277 posts

Re: Why [Insert Thing Here] Is Not a Password Killer

#241

Post by CM30 »

lowercased wrote: post #31
jrockway wrote: post #17

> Despite it's [sic] many flaws, the one thing that the humble password has going for it over technically superior alternatives is that everyone understands how to use it. Everyone. I think the problem is that people don't understand how to use passwords. They will reuse them among sites. They pick easily-guessable and low entropy ones. They will type them into any website that asks. The end result is that not much s…

i had a theory a few years back that human-chosen passwords would get simpler due to mobile keyboards. Not sure if anyone has compared leaked password dumps from before and after the great mobile-migration to see if that's happened or not.

Seems like a pretty logical theory. If you ever use a password manager on desktop and then decide you need to access the same service on mobile... well typing in that 20 character string of random characters becomes a real pain in the behind.

Though it's also quite likely a lot of users don't even remember their passwords at all now and just use password reset every time they want to log in.

Re: Why [Insert Thing Here] Is Not a Password Killer

#242

Post by saidajigumi »

ken wrote: post #134
cyborgx7 wrote: post #5

It is not just that everyone knows how passwords work. It is also that you can always enter a password. What if I don't have my phone to scan a qr-code? What if I want to use a minimalistic browser that doesn't implement a key pair store and I don't want to or can't set up one external? What if my minimal browser is text only? What if I'm on another device and don't have my stuff on there? I will pretty much always b…

Sort of. You're selectively quoting "Write programs to handle text streams, because that is a universal interface" -- but that was from the days when "text" was basically synonymous with "ASCII". Passwords aren't streams, and in the Unicode world, they're not even (predictable) byte arrays. This isn't just hypothetical. There have been recent bugs in major systems where people with non-ASCII passwords couldn't type t…

> There have been recent bugs in major systems where people with non-ASCII passwords couldn't type them.

Forget that, I've lost track of how many times I've hit the horrible bug of "site X lets me enter password Y, explicitly compliant with stated password rules, but then rejects it at login time." Either the registered password was mangled by some input sanitization/encoding, or the login password was. After some do-overs, it becomes clear that many "valid special character lists" are just plain wrong. It's 2018, and there's an appalling number of cases where someone doesn't understand that quoting/encoding ASCII/UTF-8/etc. is a 100% solved problem.

Re: Why [Insert Thing Here] Is Not a Password Killer

#243

Post by npongratz »

jniedrauer wrote: post #235
ken wrote: post #134

Earlier quoted context omitted.

Sort of. You're selectively quoting "Write programs to handle text streams, because that is a universal interface" -- but that was from the days when "text" was basically synonymous with "ASCII". Passwords aren't streams, and in the Unicode world, they're not even (predictable) byte arrays. This isn't just hypothetical. There have been recent bugs in major systems where people with non-ASCII passwords couldn't type t…

> ASCII digits are universal. Bytes are universal. Text is ... complicated. All text should be UTF-8. It really shouldn't be complicated in $current_year.

Unicode itself gets pretty complicated:

https://en.wikipedia.org/wiki/Unicode_equivalence

Re: Why [Insert Thing Here] Is Not a Password Killer

#244

Post by calhoun137 »

rocqua wrote: post #116

From the article: > I'm referring to passwordless solutions that involves things like QR codes, pictorial representations, 3rd party mobile apps, dedicated hardware devices or "magic" links sent via email. I'm not entirely sure the argument holds for the magic links sent via email. To me, those feel like lower friction that entering a password. Because all of a sudden, users don't have to remember their password. For…

This. I think Slack is doing this perfectly, they still use passwords but emphasize the magic link email. I find it a lot easier to just use the magic link the first time I join a new slack. Then once you are logged in you basically never need to log out and if you ever need to reset the password its just a click away.

Re: Why [Insert Thing Here] Is Not a Password Killer

#245

Post by rocqua »

ryan-c wrote: post #135
rocqua wrote: post #116

From the article: > I'm referring to passwordless solutions that involves things like QR codes, pictorial representations, 3rd party mobile apps, dedicated hardware devices or "magic" links sent via email. I'm not entirely sure the argument holds for the magic links sent via email. To me, those feel like lower friction that entering a password. Because all of a sudden, users don't have to remember their password. For…

There are some minor issues with the magic link workflow - one of them is security scanning software potentially visiting the link. So then you need to open the link in the same browser you want to use. But what if you want to log in on a desktop browser and only have your email on your phone? Maybe have the magic link show a couple letters you need to type into the browser?

> one of them is security scanning software potentially visiting the link.

I gave it some thought, and that seems to be solvable. Have the link go to a 'confirm' page, where the confirm button performs a post request. If security scanning software is randomly hitting post requests, that is just totally ridiculous.

What seems a lot more scary to me is the plaintext nature of e-mail. Even SMTP over TLS doesn't keep any end-points from reading your email, and I'm guessing there is a small but significant set of people who'se email providers don't run TLS.

Besides, if someone can recognize that any request is underway for a login, they might intercept it and send a phishing fake.

Re: Why [Insert Thing Here] Is Not a Password Killer

#246

Post by rocqua »

BillinghamJ wrote: post #222
ryan-c wrote: post #135

Earlier quoted context omitted.

There are some minor issues with the magic link workflow - one of them is security scanning software potentially visiting the link. So then you need to open the link in the same browser you want to use. But what if you want to log in on a desktop browser and only have your email on your phone? Maybe have the magic link show a couple letters you need to type into the browser?

They are trivially solvable problems. PKCE and just displaying a QR code if you open it on the wrong device makes it pretty much foolproof. e.g.: https://magic.cuvva.com/auth-callback?code=authzcode_000000B... We're oriented around mobile use cases. Admittedly less ideal if you don't have your email on your desktop. But ultimately, if all else fails, you can always log into your webmail. For me the key thing is that…

The QR-code thingy hits a friction barrier. For me needing to go to my phone is more friction than unlocking my password manager. Note that I only need to unlock my password manager once per reboot, and that for most people the password manager is already too much friction.

Re: Why [Insert Thing Here] Is Not a Password Killer

#248

Post by rocqua »

ilovetux wrote: post #124
rocqua wrote: post #112

Earlier quoted context omitted.

'Ugh, this site forces me to remember this shitty password, Guess I'll go to the competitor' This kind of friction is exactly what troy is talking about.

As opposed to "Oh, they want a password? I guess I'll use the same one I use for every other website." I agree that the business makes the decision, growth is the top priority and friction reduces growth, but in reality this is how most of the world already works. If you rent a hotel room you don't get to provide your own key and if you lose their key then you must prove who you are to get another one issued. In the…

Password re-use is bad, true.

But it is frictionless for the user. The entire point of the article is that trading friction for security isn't going to happen in most businesses.

Re: Why [Insert Thing Here] Is Not a Password Killer

#249

Post by cheeze »

Ajedi32 wrote: post #92
Wowfunhappy wrote: post #87

Earlier quoted context omitted.

And now that person is forever locked in to the browser they were using at sign up time. What happens if they move from Mac → Windows or Android → iOS?

As long as they use the same browser on each of those platforms, they're good. Yes, vendor lock-in is an issue; and I hope eventually there'll be a way to sync credentials across browsers. But keep in mind that, even as things are now, it only locks you to a specific browser, not to a specific OS.

Assuming your browser syncs passwords, etc.

I know a ton of people who use Chrome on non-mobile and Safari on mobile.

Re: Why [Insert Thing Here] Is Not a Password Killer

#250

Post by ggm »

cyborgx7 wrote: post #203
ken wrote: post #134

Earlier quoted context omitted.

Sort of. You're selectively quoting "Write programs to handle text streams, because that is a universal interface" -- but that was from the days when "text" was basically synonymous with "ASCII". Passwords aren't streams, and in the Unicode world, they're not even (predictable) byte arrays. This isn't just hypothetical. There have been recent bugs in major systems where people with non-ASCII passwords couldn't type t…

The idea of "text is the universal interface" informed the design of unix and it resulted in text streams. But if I apply it to something entirely different, authentication, I come out at passwords. And I wouldn't say that text meant ASCII. My understanding is that it meant text is the thing that could be understood and written by both people and computers.

The back story of the work some significant UNIX people did to get UTF8/Unicode into workable state in standards is amazing. Application of brilliant minds to a corner-case problem in international standards.

http://doc.cat-v.org/bell_labs/utf-8_history

Post reply on HN