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

81–90 of 345 posts

Re: Using HTTP Basic Auth in 2022

#81

Post by ncann »

lukevp wrote: post #65
slim wrote: post #55

Earlier quoted context omitted.

Stop passing plain passwords over the wire this is already solved by https

Only partially. If the client and server have an agreement on a hashing protocol, there’s no reason that the browser shouldn’t be able to hash as well and prevent the password from ever leaving memory on the client system. HTTPS is still vulnerable to many man in the middle attacks, and many corporate and business networks do deep packet inspection to decrypt https (they control the machines so intercepting the cert…

How do you do client side hashing without the server sending the salt/pepper to the client, which is a really bad thing?

Re: Using HTTP Basic Auth in 2022

#82

Post by jeroenhd »

lukevp wrote: post #65
slim wrote: post #55

Earlier quoted context omitted.

Stop passing plain passwords over the wire this is already solved by https

Only partially. If the client and server have an agreement on a hashing protocol, there’s no reason that the browser shouldn’t be able to hash as well and prevent the password from ever leaving memory on the client system. HTTPS is still vulnerable to many man in the middle attacks, and many corporate and business networks do deep packet inspection to decrypt https (they control the machines so intercepting the cert…

What does it matter? If a criminal gains the hash, they can log in and be malicious anyway. If a criminal can do a MitM, they can substitute the Javascript that's hashing your password with all the nonces and salts and peppers you add to it and send the password anyway.

If you just hash the password, the hash becomes the password. You're not solving the problem that way, you're just switching around definitions.

There is an alternative that's supported in most platforms, and that's WebAuthn. Not even a need for a password automatic secure handshakes and with the right protocols, the keys differ per site so they're very hard to spoof through phishing. You can achieve much of the same thing with client TLS certificates, but the UX for that is even worse than the UX for HTTP Basic.

Re: Using HTTP Basic Auth in 2022

#83

Post by oconnore »

gjsman-1000 wrote: post #67
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…

"Stop passing plain passwords over the wire." If you are using HTTPS, you are equally as good as any other login form. Some have suggested using JavaScript to encrypt passwords before send - but in my opinion, this is generally stupid because it breaks support on browsers without JavaScript, and this doesn't protect you from the server at all because a hacker could just change the JavaScript to send plaintext copies…

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

Re: Using HTTP Basic Auth in 2022

#84

Post by Waterluvian »

klysm wrote: post #27
Waterluvian wrote: post #24

Something I’m practicing more often is to keep something dead simple and then later adopt a library or some higher abstraction when necessary. For example, just handling a websocket myself before later using some sort of library for it. In the past my concern was that I’ll have to make breaking changes to some protocol or message structure. But I’m learning now that it’s actually a good thing: it makes me think about…

I find a lot of libraries don’t make the underlying systems easier to use per se, they just map a lot of use cases to configuration instead of code. I would rather just use the code hiding behind that static configuration.

After years and years of production experience with thousands of mobile robots that use this weird xml + yaml as configuration, I am 100% in the “just use code as configuration” camp.

Re: Using HTTP Basic Auth in 2022

#86

Post by thaumasiotes »

StefanKarpinski wrote: post #72
slim wrote: post #55

Earlier quoted context omitted.

Stop passing plain passwords over the wire this is already solved by https

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 than a naive password exchange, which only requires the server to store your hashed password.

There are other password protocols that require neither transmission nor server retention of the full password, but it seems worth noting that the protocol we actually have didn't bother with that.

Re: Using HTTP Basic Auth in 2022

#88

Post by RedShift1 »

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.

I love it too, when it works... When it doesn't, the users get the login prompt like the basic auth one, which can be confusing because you have no opportunity to add information to that prompt.

Re: Using HTTP Basic Auth in 2022

#89

Post by thrashh »

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

Earlier quoted context omitted.

"Stop passing plain passwords over the wire." If you are using HTTPS, you are equally as good as any other login form. Some have suggested using JavaScript to encrypt passwords before send - but in my opinion, this is generally stupid because it breaks support on browsers without JavaScript, and this doesn't protect you from the server at all because a hacker could just change the JavaScript to send plaintext copies…

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 most login forms don’t do that anyway so it wouldn’t be any worse than how things are already done.

Re: Using HTTP Basic Auth in 2022

#90

Post by freedomben »

usrbinbash wrote: post #38
Operyl wrote: post #28

Earlier quoted context omitted.

> And "Every request needs to do password validation, presenting additional load on the authentication systems/datastores" also applies to almost every login system ever made and HTTP Basic Auth doesn't make this better or worse. Not true. Once you get authenticated you can store that in a cookie with expiration, or any number of other ways to reduce load on auth services.

1. You could do the same in a BasicAuth system. 2. How is validating the session-cookie validity different from validating the username/password?

A non-trivial difference is that to validate password you need to run it through bcrypt or similar algorithm which is intentionally slow. With a token or cookie, you can use a regular fast hashing algorithm.
Post reply on HN