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

171–180 of 345 posts

Re: Using HTTP Basic Auth in 2022

#171

Post by fzzt »

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…

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 compromised account); other times, you don't want to kick out your smart thermostat and have to set it up from scratch.

Admittedly, there are some simple use cases where HTTP auth is all you need, but it's just way too inflexible, unless you turn it into some mammoth spec that is never going to be as flexible and tempting as managing user identity yourself.

Especially since HTTP auth doesn't actually mean you can stop doing that anyway. You're still handling account creation, password checking, all the abuse / bot detection bits... all you're getting rid of is the sign-on and logout functionality, which is really not that complicated to begin with.

Re: Using HTTP Basic Auth in 2022

#172

Post by teekert »

thaumasiotes wrote: post #86
StefanKarpinski wrote: post #72

Earlier quoted context omitted.

The password is still revealed to the server. 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.

> 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?

Re: Using HTTP Basic Auth in 2022

#173

Post by pests »

staticassertion wrote: post #158
gjsman-1000 wrote: post #149

Earlier quoted context omitted.

I meant, let's say I picked a framework. Django, Laravel, Express, similar. How would I implement PAKE login for my users? How would I get every user to log in with PAKE? How would I ensure that my code for PAKE could not be overwritten if a hacker took over part of my server? It doesn't exist, AFAIK, on a user-facing front at this time in a secure way that a hacker couldn't just change the logic for.

Implementing opaque isn't overly hard. You can find pseudocode, implementations, state machine diagrams, etc, online. Here's a good post that links to implemented code: https://blog.cloudflare.com/opaque-oblivious-passwords/ I know nothing of framework support, I don't use frameworks. I'm likely going to contribute some open source code in the near future from my company to simplify things though. But you could also…

What benefits would you get though?

You are still exposing the password_hash to the server and any compromise there (software or hardware, as described in your link) would still let an attacker grab password_hash, craft a custom client, and send it as if the original client had hashed the plaintext_password to begin with.

The attacker doesn't need to know plaintext_password, just the string you use to authenticate with in order to replay it. The password_hash becomes the new password.

Then due to the salt being on the client, it still opens the password up to rainbow table attacks etc.

Re: Using HTTP Basic Auth in 2022

#174

Post by na85 »

staticassertion wrote: post #127
na85 wrote: post #113

Earlier quoted context omitted.

>Yes - it does - but I am having a hard time thinking that this actually matters in the real world. In the 90s and early aughts it was fashionable for php sites to store passwords hashed, usually some combination of a salt with md5 and later the SHA variants. For a brief few years there were entire communities on IRC and elsewhere dedicated to making rainbow tables for cracking stolen password hashes. Often the salt…

A trivial fix here is to: a) Add a static value to the salt ie: your company's name b) Add the user's email address to the salt The "right" way would be a zero knowledge proof.

Yeah well PHPnuke wasn't exactly written by secure coding experts.

Re: Using HTTP Basic Auth in 2022

#175

Post by klodolph »

diarrhea wrote: post #154
klodolph wrote: post #60

Earlier quoted context omitted.

Why would you need to index it by the clear-text password? You don't need to retrieve the clear-text password, it doesn't have to be stored in the cache at all. The cache itself would be in the memory of a process which had access to cleartext passwords anyway, so presumably an exploit which allowed you to read the cache would be damning no matter what.

The parent commenter possibly meant: with an incoming request, sending a password in clear-text, how do you cache it? You hash it, then store the fact that authentication was valid with some expiry. Once the next request, again with clear-text password, comes in you need to look up its validity. You want to check without hashing , that's the entire point. If you look up whether the hash is validly cached, you gained…

> You want to check without hashing, that's the entire point.

It's not the point. There is no attempt to avoid hashing.

At this moment I'd like to be careful and distinguish between ordinary cryptographic hash functions (SHA-2, BLAKE2, etc) and key derivation functions (PBKDF2, Argon2, etc), even though both are often referred to as "hashing" in this context.

The thing about key derivation functions is that they make brute force attacks harder, because the computational cost of verifying the password is higher. They are typically parameterized so you can adjust verification cost. This is the cost we want to avoid.

However, just because you are not using your ordinary key derivation function with the parameters you normally use, it does not mean the only other option is to store passwords in plain text. You could use a key derivation function with different parameters, an HMAC with an ephemeral secret, or an ordinary cryptographic hash. These are all options, with different security tradeoffs.

Part of the evaluation of key derivation functions and their parameters is the evaluation of the risk that the hashed value is compromised. These values are stored in files or in databases, and there is a correspondingly higher risk of compromise... e.g. through backups. Your conclusions would be different for an in-memory cache which is harder to compromise and contains fewer entries, so you would naturally choose a different way of storing the passwords. Different algorithms or different parameters.

(There are also other interesting solutions around... like using an HSM to MAC the passwords.)

Re: Using HTTP Basic Auth in 2022

#176

Post by staticassertion »

pests wrote: post #173
staticassertion wrote: post #158

Earlier quoted context omitted.

Implementing opaque isn't overly hard. You can find pseudocode, implementations, state machine diagrams, etc, online. Here's a good post that links to implemented code: https://blog.cloudflare.com/opaque-oblivious-passwords/ I know nothing of framework support, I don't use frameworks. I'm likely going to contribute some open source code in the near future from my company to simplify things though. But you could also…

What benefits would you get though? You are still exposing the password_hash to the server and any compromise there (software or hardware, as described in your link) would still let an attacker grab password_hash, craft a custom client, and send it as if the original client had hashed the plaintext_password to begin with. The attacker doesn't need to know plaintext_password, just the string you use to authenticate wi…

If the attacker only has access to the hash that hash is only usable for your website. If the user uses the same password for another site an attacker can not log into that other site using the hash.

That's really the main benefit of this approach - it reduces the impact of password reuse.

Re: Using HTTP Basic Auth in 2022

#179

Post by thorum »

As a counterpoint, learning the basics of a good OAuth library or service like oauth2-proxy, auth0, next-auth or keycloak is well worth your time as a developer. Once you get over the initial learning curve, it’s almost as easy to add to a project as basic auth. You don’t need to reinvent the wheel with each project, building login pages and database code - other people have done the work for you - and you can create a more usable and professional experience for your users.

Re: Using HTTP Basic Auth in 2022

#180

Post by jstummbillig »

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…

> It's not a massive amount of work

Oh, sweet summer child

Post reply on HN