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

201–210 of 345 posts

Re: Using HTTP Basic Auth in 2022

#201

Post by madacol »

gjsman-1000 wrote: post #153
dllthomas wrote: post #139

Earlier quoted context omitted.

You've responded as if the bit you've quoted is advice to individual developers in the present context, but the topic of conversation was about extending browsers so that the standard login form would do this (... better than existing auth digest). If we did that and people were used to using the browser's built-in login dialog, and (as with https) we made it visible what security features were enabled, then a trivia…

Right... that would be awesome. But it would still be susceptible to a hacker replacing it with a traditional login page with some logging... unless somehow you could prevent any traditional web pages from working.

And users WILL NOTICE before that happens

Please, stop using those strawman arguments

Re: Using HTTP Basic Auth in 2022

#202

Post by thaumasiotes »

teekert wrote: post #172
thaumasiotes wrote: post #86

Earlier quoted context omitted.

> There are password verification protocols where the password is not revealed to the server either, which is much more secure as it means that you’re not at the mercy of whether the sever operator follows good security practices about not saving your password in plain text somewhere. Well, the most common such protocol is TOTP, which still requires the server to store your full password. In that sense it's worse tha…

Does it matter if the pw is stored salted and hashed?

Yes, that's why we do that.

I'm not sure what you want to ask.

Re: Using HTTP Basic Auth in 2022

#203

Post by yuliyp »

hiptobecubic wrote: post #21
yuliyp wrote: post #13

This has many flaws that make it impractical beyond hobby projects or projects with a small set of users: - It's trickier to throttle credential checks as every request is a login request, effectively - It's hard to easily build account recovery flows or captchas into the login process. - The UX of logging in/out is browser-dependent and confusing for users - it can't integrate well with other auth systems - Sending…

Did you even read the post?

Yes, I did. Hence why I pointed out one of the characteristics that made it work fine in the scenario mentioned (that it has a relatively small set of users that can be trained), and many of the concerns I mentioned are not particularly applicable to the situation which the OP presented. I was making the point that the OP's success is not necessarily transferable to large scale applications.

Re: Using HTTP Basic Auth in 2022

#204

Post by gjsman-1000 »

madacol wrote: post #201
gjsman-1000 wrote: post #153

Earlier quoted context omitted.

Right... that would be awesome. But it would still be susceptible to a hacker replacing it with a traditional login page with some logging... unless somehow you could prevent any traditional web pages from working.

And users WILL NOTICE before that happens Please, stop using those strawman arguments

I beg to differ. You'd be surprised how many users probably would not recognize any difference whatsoever as long as the hacker got things looking relatively identical.

Re: Using HTTP Basic Auth in 2022

#206

Post by throwawayboise »

VTimofeenko wrote: post #68
foepys wrote: post #41

Earlier quoted context omitted.

> doesn't work well with password managers, how to new team members learn the password, no easy way to rotate passwords when offboarding This is where LDAP and similar are really strong. Unfortunately a lot of companies know that and charge big bucks for this simple feature, often hiding it behind "enterprise" subscriptions where you need to contact them for pricing. It's also the reason why companies love Exchange a…

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.

Re: Using HTTP Basic Auth in 2022

#207

Post by wswope »

staticassertion wrote: post #194
wswope wrote: post #188

Earlier quoted context omitted.

If I’m understanding your argument correctly (I may not be) - implementing PAKE would only be helpful in a scenario where an attacker gets access to hashed passwords, but isn’t able to modify front-end code to directly intercept unhashed passwords, right?

You are correct. I (and I think most people?) consider that to be the most common attacker scenario.

Gotcha - and I can definitely see the utility with a large userbase.

From a corporate perspective, with a segmented + well-firewalled architecture, and a lot of surface area for injection vulns, I totally agree with you. The article was priming me to think of a flat, single-box solodev environment, where if someone breaks in, they own everything - which is why I think the original post above us mentioning PAKE is getting a lot of questioning.

Re: Using HTTP Basic Auth in 2022

#208

Post by yuliyp »

usrbinbash wrote: post #36
yuliyp wrote: post #13

This has many flaws that make it impractical beyond hobby projects or projects with a small set of users: - It's trickier to throttle credential checks as every request is a login request, effectively - It's hard to easily build account recovery flows or captchas into the login process. - The UX of logging in/out is browser-dependent and confusing for users - it can't integrate well with other auth systems - Sending…

>This has many flaws that make it impractical Just because something is simple doesn't make it impractical. Not every application requires a complex auth-flow. >As every request is a login request, effectively This is the case with basically every single Authentication flow in existence...at the end of the day, no matter how and where credentials are verified, there is a token that has to be sent with every request a…

> impractical

Completely agree. My points generally apply a lot more to large scale systems.

> every request is a login request

While it's true that every request has something being verified for authentication purposes, login is a higher risk activity: username/password can get harvested in lots of ways, while session cookies etc. generally are harder to steal, meaning there is less risk of an attacker being present with auth cookies vs seeing a username / password

> account recovery

The way I've seen browsers implement password auth generally blocks interacting with the rest of the page. While a normal login form might have a "forgot password / email" link, with basic auth the user is stuck with a modal that the web site owner has no control over and cannot build such affordances.

> integration with other auth systems

In general, other auth systems take a set of credentials and then issue a token that can be used for further authentication. Basic Auth's design is that the same credential is used for every request. I guess you could build a hybrid auth system that can accept either cookies/headers from an alternative system, or basic auth and just have some sort of rules for dealing with what happens if both are present, but at that point why not just use a normal login page if you're already dealing with support for session tokens of some sort?

Re: Using HTTP Basic Auth in 2022

#209

Post by fzzt »

madacol wrote: post #186
fzzt wrote: post #171

Earlier quoted context omitted.

There's a lot more to that. A bank doesn't want the "back" button to work forever; they want to control the lifetime of your session, ideally on the server. Google wants to let you sign into multiple accounts on the same origin. Many others want to have seamless single sign-on across several of their web properties. Sometimes, you want the change of your password to invalidate other sessions (say, when recovering a c…

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 probably a reasonable goal. That said, it's more readily approximated with unique passwords + having a good password manager. The main risk of password leaks is not that they make that particular breach worse (since the attackers can just grab your data), but that passwords are reused too often.

Federated login is another approximation, where the password is only known to your identity provider, not to every identity consumer. It's modestly successful for some lower-value services.

Re: Using HTTP Basic Auth in 2022

#210

Post by floatingatoll »

forgotmypw17 wrote: post #23

I use it as a captcha. It's great for keeping crawler bots out, and easy enough for humans to get past. Once a user logs in, I set a cookie, and the user is not prompted for the auth again. The beautiful thing about this scheme is that the cookie is always sent, so I can create a rule which bypasses auth when the cookie is present. Basic Auth is one of the most supported features of HTTP, supported even by Mosaic. Th…

This is my preferred use of basic auth: just set the message to “enter anything for username and password” and accept anything. Search crawlers won’t be able to index the site, which protects me from haters finding my content, and RSS feed urls can just hardcore some u/p without consequence. It’s all the upsides of the modern web without any of the harmful behaviors enabled by global search engines.
Post reply on HN