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

Using HTTP Basic Auth in 2022

joeldare.com

Post reply on HN
Print view View original

331–340 of 345 posts

Re: Using HTTP Basic Auth in 2022

#331

Post by nirui »

jannes wrote: post #318
nirui wrote: post #270

Earlier quoted context omitted.

Is there any chance to go even further than this? I'm imaging a public key based authentication scheme. The user submit their public key to the server first, then in the feature logins, server will generate a challenge for client to decrypt and respond. Of course the browser can apply some UX magic at the client end, for example displaying a pop window to allow user to select a public key for the authentication proce…

Sounds like client certificates. I guess you have never used those. All major browsers support them. In Firefox you can find them here: Settings -> Privacy & Security -> View Certificates -> Your Certificates

Yes, but the advantage is that the user sends their own public keys and they can switch it freely (and preferably easily, user click "login", a window pop up, user select a public key, done) at will. While client certificates is currently managed fully by the browser, and you need to adjust your HTTPS infrastructure in order to enable the feature.

Re: Using HTTP Basic Auth in 2022

#332

Post by usrbinbash »

yuliyp wrote: post #322
usrbinbash wrote: post #289

Earlier quoted context omitted.

> username/password can get harvested in lots of ways, BasicAuth isn't more at risk of this than other methods however. Unless a website doesn't use HTTPS, but if that's the case, all talk about security is out the window anyway. > The way I've seen browsers implement password auth generally blocks interacting with the rest of the page. BasicAuth Challenge -> Wrong Password -> Server replies with 200 + "Did you forge…

My comment about username/password being harvested was talking about how someone's password can get stolen: you can have malware, password reuse across sites, phishing, or other social engineering. For session cookies, you have basically malware as the compromise vector. Hence, passwords should be treated with more suspicion by an authentication system.

All these attack vectors work regardless of the Authentication system used.

Re: Using HTTP Basic Auth in 2022

#333

Post by Kalium »

jamil7 wrote: post #241
Kalium wrote: post #227

Earlier quoted context omitted.

Thank you! This is a deeply underappreciated point. I understand how annoying, painful, and disruptive to the user experience it is to have part of your app taken over by browser or OS default widgets and behavior is. It's sheer hell on UX. Yet the custom styling that would make it integrate smoothly would be a godsend for attackers and phishers. The role that UX - and misuses of UX - play in security is often not co…

Is this actually hell on UX or is that something product people and designers tell us because it’s in their personal interest to create custom solutions for every webapp? iOS apps pretty regularly defer user actions to OS level controls and prompts and frankly I believe the UX there is far superior to webapps using bespoke UX for these. Wouldn’t standardised browser behaviour and OS level styling for common flows and…

Like you, I suspect it's not, but I've found that leading with telling people that the thing they deeply want to believe is wrong is a poor way to convince them of things. You have to go through a ritualistic performance of empathy first.

Re: Using HTTP Basic Auth in 2022

#334

Post by Kalium »

cobbzilla wrote: post #310
merlinscholz wrote: post #161

Earlier quoted context omitted.

Please do not add logo customization. This will end with prompts asking you for your Apple and Microsoft passwords which are difficult to differentiate from official prompts (at least for end users).

What if the icons are NFTs with automated browser verification? I’m only half joking— could this actually be doable?

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 challenging and like a hacky re-implementation of a trademark system.

Re: Using HTTP Basic Auth in 2022

#335

Post by Kalium »

maficious wrote: post #244
Kalium wrote: post #227

Earlier quoted context omitted.

Thank you! This is a deeply underappreciated point. I understand how annoying, painful, and disruptive to the user experience it is to have part of your app taken over by browser or OS default widgets and behavior is. It's sheer hell on UX. Yet the custom styling that would make it integrate smoothly would be a godsend for attackers and phishers. The role that UX - and misuses of UX - play in security is often not co…

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.

Re: Using HTTP Basic Auth in 2022

#336

Post by yuliyp »

usrbinbash wrote: post #332
yuliyp wrote: post #322

Earlier quoted context omitted.

My comment about username/password being harvested was talking about how someone's password can get stolen: you can have malware, password reuse across sites, phishing, or other social engineering. For session cookies, you have basically malware as the compromise vector. Hence, passwords should be treated with more suspicion by an authentication system.

All these attack vectors work regardless of the Authentication system used.

They don't, though. Users don't reuse session cookies between sites, so another site compromised doesn't mean you have to worry about existing sessions being compromised on your site. Users also don't know their session cookies so are far less likely to go typing them in to a phishing site or hand them out over the phone. A password is vulnerable to all of these scenarios.

Re: Using HTTP Basic Auth in 2022

#337

Post by jeofken »

lukevp wrote: post #93
jeofken wrote: post #34

Earlier quoted context omitted.

Implementing magic email sign in links is more straightforward and secure. You implement a login route which takes an email address. You symmetrically encrypt the email with a secret key from an environment variable, and send a link to /login?secret= . This route handler checks that the ciphertect decrypts into the email, and if true, save the ciphertext as a cookie and check that it decrypts to the right email every…

So anyone who compromised the cookie can login as this user forever? There’s no expiration or revocation in this protocol. Once you layer on expiration, this is basically sending someone a link with a JWT in the get request. Or you can hit the DB to check a secret key that’s in the email, and if it has expired, but this is worse than JWT because it requires a DB to verify the identity, where JWTs can be verified with…

Oh yeah of course you must do all those things! Assumed it was obvious that this was only about the steps leading up to giving the JWT token. Wrote it with one hand on my phone :-)

Re: Using HTTP Basic Auth in 2022

#338

Post by VTimofeenko »

throwawayboise wrote: post #206
VTimofeenko wrote: post #68

Earlier quoted context omitted.

Technically as far as I understand the client side certificates and signing/revoking them through internal CA solve the same problems. However I have yet to encounter such setup used in a professional environment for humans. Is the complexity of such approach just too high compared to LDAP and the passwords?

Normal users (including some people with graduate degrees in computer science) can't manage client-side keys or certificates, as anyone who has ever had to support users using ssh key authentication knows. So then you have to provide functionality to do this for them in a foolproof and secure way, which is a big bite to chew.

Yeah, I figured the end-user support would fall under the abstract "complexity" I mentioned in my original comment. I can build a hotrod in my garage but nobody sane will use it for public transportation.

Re: Using HTTP Basic Auth in 2022

#340

Post by cobbzilla »

Kalium wrote: post #334
cobbzilla wrote: post #310

Earlier quoted context omitted.

What if the icons are NFTs with automated browser verification? I’m only half joking— could this actually be doable?

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 solution is for the branding to consist entirely of NFT assets that can all be tracked to a definitive owner, and use some DNS-based glue (ala DKIM/SPIF for email) to link the NFT to the TLD.

Then your browser can refuse to show the MSFT logo (and show a big red fraud alert page) if the owner of the branding can’t be reliably traced back to Microsoft (owner of the site).

Post reply on HN