Using HTTP Basic Auth in 2022 • Hacker News Board

Re: Using HTTP Basic Auth in 2022

#341

Post by Kalium » Tue, Jan 04, 2022, 2:05 PM UTC

cobbzilla wrote: post #340

Kalium wrote: post #334

Earlier quoted context omitted.

Verification of what, precisely? That it's authorized for the domain it's on? This seems like a re-implementation of existing access control systems, with the same weakness of being vulnerable to being copied. Unless you're somehow able to get everyone to transition at once, never support a non-NFT fallback and, ensure that no sufficiently visually similar logo ever gets registered... which IMO sounds both challengin…

This would be verification that any branding on the HTTP Basic Auth popup represents the company it claims to. This would be optional — any site that didn’t use this would still have the default (generic/unbranded) browser behavior. The stated (and valid) concern is that malicious actors would use fraudulent branding on those browser auth popups — let’s tell the user we are MSFT or AAPL and steal their password. One…

At this point you're talking about checking a signature. Naively, it seems to me like you could skip the NFT entirely and embed a verifiable sig in a securely delivered DNS record. Then it's linked to the domain. You can do this now, with tooling that already exists and is deployable today. You'd need to deliver the record securely to avoid attacks on the glue anyway.

Of course, neither the NFT nor the sig-in-DNS approach actually solves the problem of a visually identical but technically different image (use a slightly different color in a few places, etc.) being used to trick people. I'm not sure what we've gained. The malicious use case would seem like it's not effectively prevented.

Re: Using HTTP Basic Auth in 2022

#342

Post by cobbzilla » Tue, Jan 04, 2022, 6:27 PM UTC

Kalium wrote: post #341

cobbzilla wrote: post #340

Earlier quoted context omitted.

This would be verification that any branding on the HTTP Basic Auth popup represents the company it claims to. This would be optional — any site that didn’t use this would still have the default (generic/unbranded) browser behavior. The stated (and valid) concern is that malicious actors would use fraudulent branding on those browser auth popups — let’s tell the user we are MSFT or AAPL and steal their password. One…

At this point you're talking about checking a signature. Naively, it seems to me like you could skip the NFT entirely and embed a verifiable sig in a securely delivered DNS record. Then it's linked to the domain. You can do this now, with tooling that already exists and is deployable today. You'd need to deliver the record securely to avoid attacks on the glue anyway. Of course, neither the NFT nor the sig-in-DNS app…

You’re right. Both about the problem still being present and NFT being not strictly necessary anyway.

I can’t help but think there must be a way to make it work.

Re: Using HTTP Basic Auth in 2022

#343

Post by Kalium » Tue, Jan 04, 2022, 6:46 PM UTC

cobbzilla wrote: post #342

Kalium wrote: post #341

Earlier quoted context omitted.

At this point you're talking about checking a signature. Naively, it seems to me like you could skip the NFT entirely and embed a verifiable sig in a securely delivered DNS record. Then it's linked to the domain. You can do this now, with tooling that already exists and is deployable today. You'd need to deliver the record securely to avoid attacks on the glue anyway. Of course, neither the NFT nor the sig-in-DNS app…

You’re right. Both about the problem still being present and NFT being not strictly necessary anyway. I can’t help but think there must be a way to make it work.

There probably is, provided you can get a perceptual model that correctly models all human visual perception and reduce it to a hash. I am not sure one exists currently. Until then, it really does seem like we're trying to find a way to re-implement trademarks in a way that doesn't require the interpretive work that trademarks rely on.

I suspect there's a lot of complexity hidden in the perceptual model requirement, though.

Re: Using HTTP Basic Auth in 2022

#344

Post by madacol » Wed, Jan 05, 2022, 12:41 AM UTC

fzzt wrote: post #209

madacol wrote: post #186

Earlier quoted context omitted.

Maybe we don't want them to be able to do any of that And I think you are missing the point, the goal it's not to standardize logins, it's about making impossible for servers to know my password, hence impossible passwords leaks That would allow people to reuse strong passwords, and not need passwords managers, because that's what they are doing anyway!

> Maybe we don't want them to be able to do any of that "We" who? Application owners want that, browser vendors want that (their greatest fear is that mobile will eat the web, so they don't want to make the platform less flexible)... and users generally don't mind. > impossible for servers to know my password, hence impossible passwords leaks That would require deeper architectural changes to HTTP auth, but is probab…

We = users *

Re: Using HTTP Basic Auth in 2022

#345

Post by maficious » Wed, Jan 05, 2022, 9:33 AM UTC

Kalium wrote: post #335

maficious wrote: post #244

Earlier quoted context omitted.

What prevents the hacker from cloning the whole web-page of, say, facebook.com login and phish users for credentials this way? This is not a hyphotetical thing, Kali Linux even bundles a utility program for that. Compared to that, one icon, that is the same as that of the company, is not that threatening. Not only that, but if you consider a sign in form that wouldn't have a logo, it would be way easier to trick user…

As you say, nothing at all. I think the real answer is that allowing this kind of deep and arbitrary styling of interfaces is far more dangerous than it is helpful.

Let's ban CSS?