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

241–250 of 345 posts

Re: Using HTTP Basic Auth in 2022

#241

Post by jamil7 »

Kalium wrote: post #227
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).

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 behaviour be a big win for webapps and take some of the drudgery out of web development?

Re: Using HTTP Basic Auth in 2022

#242

Post by francislavoie »

mmcnl wrote: post #230
mholt wrote: post #61

Caddy comes with basic auth support because it's still useful for a lot of use cases. IMO the biggest weakness of basicauth (when deployed over TLS) is the fact that most server configurations store the passwords in plaintext, usually in a config file. This is like storing passwords in plaintext in a database. Caddy does not allow this. You have to use a secure hash on the password before adding it to your config: ht…

Caddy is truly amazing. Thanks for that. Tip for me would be to improve the documentation and add more examples, just to get the hang on what the Caddyfile philosophy is. I've spent literally hours just to come up with a single line in a Caddyfile (and in the end it worked).

This page explains the structure of a Caddyfile: https://caddyserver.com/docs/caddyfile/concepts. What are you missing from there?

Re: Using HTTP Basic Auth in 2022

#243

Post by IggleSniggle »

mholt wrote: post #61

Caddy comes with basic auth support because it's still useful for a lot of use cases. IMO the biggest weakness of basicauth (when deployed over TLS) is the fact that most server configurations store the passwords in plaintext, usually in a config file. This is like storing passwords in plaintext in a database. Caddy does not allow this. You have to use a secure hash on the password before adding it to your config: ht…

I’m confused by this. If you have the username, the hashed password, the salt, and the algorithm used, all present in the config file, then what’s the difference between doing what caddy does here and just having the plaintext password in the config file? Isn’t that just the same thing but with extra (known) steps?

Not trying to be intentionally dense, genuine confusion/question.

Re: Using HTTP Basic Auth in 2022

#244

Post by maficious »

Kalium wrote: post #227
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).

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 into putting their credentials in, because the user wouldn't be able to differentiate them. Also OAuth is always branded AFAIK.

Users may also notice discrepancies in the logo, if it was cloned poorly. Though I can't think of a way someone couldn't forge a logo given all the possibilities. Adobe Illustrator can trace images into svg and there's plenty of companies' svg logos just in the google search.

Re: Using HTTP Basic Auth in 2022

#245

Post by bnf »

zorr wrote: post #100
loevborg wrote: post #32

Earlier quoted context omitted.

I do the same, e.g. to expose static resources like API docs in an S3 bucket to the world (you can configure CloudFront to check Basic Auth). However, at some point you run into issues (doesn't work well with password managers, how do new team members learn the password, no easy way to rotate passwords when offboarding, etc.). Now I want to upgrade to a proper OAuth wall. Some server needs to act as a reverse proxy t…

I used vouch-proxy with nginx for something like this. The nginx auth_request module authenticates each request against vouch-proxy before it executes the proxy_pass. Vouch-proxy can be configured to authenticate users against google apps or other oauth/iodc providers. And there are some options to pass along username, groups or other data as headers to the proxied service.

Vouch Proxy author here. Thanks for the mention @zorr

VP can be found at https://github.com/vouch/vouch-proxy

Here's to a safe, secure and authenticated 2022!

Re: Using HTTP Basic Auth in 2022

#246

Post by nvllsvm »

IggleSniggle wrote: post #243
mholt wrote: post #61

Caddy comes with basic auth support because it's still useful for a lot of use cases. IMO the biggest weakness of basicauth (when deployed over TLS) is the fact that most server configurations store the passwords in plaintext, usually in a config file. This is like storing passwords in plaintext in a database. Caddy does not allow this. You have to use a secure hash on the password before adding it to your config: ht…

I’m confused by this. If you have the username, the hashed password, the salt, and the algorithm used, all present in the config file, then what’s the difference between doing what caddy does here and just having the plaintext password in the config file? Isn’t that just the same thing but with extra (known) steps? Not trying to be intentionally dense, genuine confusion/question.

It's essentially impossible to reverse the hashed password. This is particularly helpful for users who reuse the same password for everything online.

Re: Using HTTP Basic Auth in 2022

#247

Post by lordlimecat »

gjsman-1000 wrote: post #91
oconnore wrote: post #83

Earlier quoted context omitted.

No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_k…

> "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I…

Scenario 1: Attacker compromises ECOMMERCE_SITE where you have a login. The ECOMMERCE_SITE uses md5 for logins, so the attacker just brute-forces the hash and then uses that password to compromise your logins on other sites.

Scenario 2: The ecommerce site has upgraded to SHA512, so cracking isnt an option. But the site is relying on basic auth, so the attacker simply sniffs your password when you auth.

Scenario 3: the ecommerce site is using a secure zero-knowledge auth against a hashed/salted/peppered/whatever credential. They cannot brute force it, and the server never sees your password. They can mess around with the ECOMMERCE_SITE but cannot pivot to any of your other logins.

>If I was a hacker, I can add JavaScript to send plaintext somewhere.

We've just shifted from "quiet, persistent threat" to "hacker announces to the world that he's in". Changing javascript on a prod website is going to trigger alarms.

Re: Using HTTP Basic Auth in 2022

#248

Post by throwaway81523 »

marcosdumay wrote: post #222
gjsman-1000 wrote: post #91

Earlier quoted context omitted.

> "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I…

Zero knowledge proofs protect against the password leaking due to any kind of error from the server. That's not security theater, passwords leak all the time. And the nice thing is that browsers already implement that, no need for Javascript. The bad news is that the UX sucks so much that you just can not use, so it's as useful as it not being there. But digest password authentication protects against nearly none of…

> Zero knowledge proofs protect against the password leaking due to any kind of error from the server. That's not security theater, passwords leak all the time.

That's a little confused. PAKE usually still stores a password or hashed password on the server, with the password potentially recoverable by brute force reversing the hash. What it avoids is transmitting a hash over the wire that can be reversed into a password, the way HTTP digest auth allows. The stuff transmitted over the wire by PAKE instead reveals no info about the password.

Most login pages on web sites today send the cleartext password underneath the https encryption layer, so the server sees the password (though hopefully stores it in only in hashed or MAC'd form). That is equivalent to http basic auth sent through https.

I use basic auth + https for my own stuff (where I don't care about styling) and it suffices for most things. Obviously you can escalate from there to 2fa, client certificates with credentials wrapped in hardware tokens, or whatever. I haven't needed that for personal stuff so far.

Re: Using HTTP Basic Auth in 2022

#249

Post by lordlimecat »

merlinscholz wrote: post #161
zimbatm wrote: post #48

HTTP Basic Auth could be so much better with a little help from browsers. If it was a bit better, most websites wouldn't need to implement login pages over and over again. Plus it would be more secure since the popup is in its own security context. * Add a button to log out. Logout never really worked across browsers with basic auth. * Allow to inject a logo or a tiny bit of customization for branding. The default po…

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

You can already do this.

As always the only defense is to compare what is being asked for with the FQDN.

Re: Using HTTP Basic Auth in 2022

#250

Post by [deleted] »

adamzochowski wrote: post #75
zimbatm wrote: post #48

HTTP Basic Auth could be so much better with a little help from browsers. If it was a bit better, most websites wouldn't need to implement login pages over and over again. Plus it would be more secure since the popup is in its own security context. * Add a button to log out. Logout never really worked across browsers with basic auth. * Allow to inject a logo or a tiny bit of customization for branding. The default po…

One of my favourite auth is the NTLM/SSPI which came out of the the windows NTLM world. Users don't even see they are being asked to be authenticated, they are either logged in, or told they don't have access. Works great in corporate world.

[deleted]
Post reply on HN