Using HTTP Basic Auth in 2022 • Hacker News Board

Re: Using HTTP Basic Auth in 2022

#321

Post by fulafel » Sun, Jan 02, 2022, 5:49 PM UTC

cookiengineer wrote: post #305

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…

Imagine a HTTP Basic Auth workflow that has another "Token: ..." header that is based on TOTP. This would help make things so much better compared to what's the situation right now. The stuff we see nowadays is mostly hacks that upgrade legacy systems with things like "the password is actually your-password#token" and "oh yeah, if you use # in your password, it crashes the server ... so don't do that". Something like…

That wouldn't be basic authentication any more which is by definition username+password. HTTP currently already supprots other authentication types besides basic auth, such as digest and bearer authentication. Bearer is rather close to what you describe.

Re: Using HTTP Basic Auth in 2022

#322

Post by yuliyp » Sun, Jan 02, 2022, 6:01 PM UTC

usrbinbash wrote: post #289

yuliyp wrote: post #208

Earlier quoted context omitted.

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

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

Re: Using HTTP Basic Auth in 2022

#323

Post by amluto » Sun, Jan 02, 2022, 6:24 PM UTC

thesz wrote: post #300

eru wrote: post #288

Earlier quoted context omitted.

You could make the line of death better. In the context of the pop-up: a simple pop up can be faked. But what if the browser would flash all the borders (and other stuff outside the line of death) when the real popup is displayed? I'm not saying any of this is 100% foolproof, just that we should be doing some UI experiments on real people to see what works better.

This is what was done in the EROS [1] (extremely reliable operating system) UIs - it was not possible for user window to be rendered completely undistinguishable from system windows like, you knew it, a password prompt. [1] https://en.wikipedia.org/wiki/EROS_(microkernel) EROS used capabilities to enforce such rules. If you lack a capability to be a system window, you can't pretend to be one.

This is also what a secure attention key is for. Sadly the well known implementation (Windows NT) made it sufficiently obnoxious that it went away.

I can imagine keyboards having a special “password” key and trying to train people that all passwords start with the password key. I don’t know if this would work, but it can’t be worse than Ctrl-alt-delete.

Re: Using HTTP Basic Auth in 2022

#324

Post by alerighi » Sun, Jan 02, 2022, 7:34 PM UTC

jeroenhd wrote: post #216

alerighi wrote: post #215

Earlier quoted context omitted.

As every other login form does. In this situation basic authentication is no different from every other authentication mechanism that uses passwords...

Not necessarily, you can set up TLS client auth with signed certificates, generated locally, that the server never receives the private key of. The server can validate and authenticate without knowledge of the secret, and cannot impersonate the user. The problem with TLS client certs, of course, is the fact you need a method of signing CSR's, and the terrible UX modern browsers have for client auth, especially on mob…

Yes in theory you can but it's a pain, a certificate needs to be installed in the browser, the user gets a popup every time saying that you want to use a certificate, when the user changes computer either needs to backup the certificate or install it again, etc. My bank did that in the past and they no longer support that, instead they opted for a classical multiple factor authentication: password + authorize the access with your phone.

Re: Using HTTP Basic Auth in 2022

#325

Post by creeble » Sun, Jan 02, 2022, 7:40 PM UTC

devmunchies wrote: post #96

I like basic auth (Header of `Authorization: Basic username:password`) but for persistent session auth I prefer the Bearer tokens[1][2] (Header of `Authorization: Bearer my_token_here`). It's easy to generate a hash after the user logs in and then just store it in a cookie. The user doesn't have to store their password locally and I can delete the token from the database to force them to re-login. You can reuse the s…

Surprised there aren’t more comments here - does everyone agree that this is equivalent (in security terms) to using JWT?

I would very like to never use JWTs again.

Re: Using HTTP Basic Auth in 2022

#326

Post by forgotmypw17 » Sun, Jan 02, 2022, 8:43 PM UTC

yjftsjthsd-h wrote: post #267

forgotmypw17 wrote: post #231

Earlier quoted context omitted.

Thanks for the tip about Chrome 49. I'll add it to my list of browsers to test with more frequently. 65.x happens to be the last version added to Ubuntu 13.x, which is what one of my devices came installed with and I'm not motivated to change.

Why would you stick with Ubuntu 13.x? It's not even a LTS version

It's what came with the machine and works fine for my purposes.

Re: Using HTTP Basic Auth in 2022

#327

Post by devmunchies » Sun, Jan 02, 2022, 9:18 PM UTC

creeble wrote: post #325

devmunchies wrote: post #96

I like basic auth (Header of `Authorization: Basic username:password`) but for persistent session auth I prefer the Bearer tokens[1][2] (Header of `Authorization: Bearer my_token_here`). It's easy to generate a hash after the user logs in and then just store it in a cookie. The user doesn't have to store their password locally and I can delete the token from the database to force them to re-login. You can reuse the s…

Surprised there aren’t more comments here - does everyone agree that this is equivalent (in security terms) to using JWT? I would very like to never use JWTs again.

i listen to a few cryptography podcasts and cryptography is an interest of mine[1]. most security engineers agree that JWT has too much of a surface area and takes a lot of care from the implementer that it can lead to security holes[2].

Another reason i like just generating a securiity token when the user logs in is that i can require a join on the table for any query so that its extra secure.

e.g. if fetching "posts" for a "user" and i have 3 tables (users, posts, and user_tokens) i can do an inner join like this (if the `posts` table has `user_id`):

  select p.*
  from posts p
  inner join user_tokens ut using (user_id)
  where p.user_id = $1 and ut.token = $2
    
  -- `users` table wasn't needed for this join since am not selecting from it

with JWTs the security happens once when you verify the JWT signature, but then security is less of a focus when making queries, which would complicate queries anyway since you have to make sure the same user who owns the JWT has access to the data (it handles authentication but not authorization). You still need to hit the database anyway for fetching any data so the headless approach for JWTs isn't really saving me much, so I like to just bake in security for the queries.

[1]: I recommend new book "Real World Cryptography" by David Wong

[2]: (podcast about JWTs from cryptographer, august 2021) https://securitycryptographywhatever.buzzsprout.com/1822302/...

--

EDIT: would probably want a few more predicates in that query to account for token status.

e.g.

  where p.user_id = $1 and ut.token = $2
  and ut.is_revoked = false and ut.is_expired = false

Re: Using HTTP Basic Auth in 2022

#328

Post by pronoiac » Sun, Jan 02, 2022, 11:48 PM UTC

diarrhea wrote: post #306

pronoiac wrote: post #234

Earlier quoted context omitted.

Have you checked if the secret path leaks in referrers?

It doesn't seem so. Clicking a random link from inside the Vaultwarden webpage (which is never used anyway, in favor of the Bitwarden browser plugins) and following the requests in Firefox's Browser Console, no request has a Referer HTTP request header. Vaultwarden does not send the Referer header cross-origin: https://github.com/dani-garcia/vaultwarden/blob/920371929bc8... My home server uses Caddy and its JSON logs…

That's a good way to investigate; I would've pointed to a server I control and check the logs.

Re: Using HTTP Basic Auth in 2022

#329

Post by Waterluvian » Sun, Jan 02, 2022, 11:49 PM UTC

jacobsenscott wrote: post #261

gedy wrote: post #238

Earlier quoted context omitted.

Compiled languages had a harder time with this.

Even with interpreted languages - if your configuration is in code you still need to wait for a code review, wait for CI to pass, and wait for the deploy. It can easily take over an hour to do a simple configuration change.

You say it like any of that is a bad thing.

Generally speaking, I think configuration changes should be reviewed.

Re: Using HTTP Basic Auth in 2022

#330

Post by u801e » Mon, Jan 03, 2022, 4:33 AM UTC

Too wrote: post #291

huntertwo wrote: post #221

Earlier quoted context omitted.

If the hash is used to authenticate, how is leaking the hash less bad than leaking the password? If I have the hash I can already impersonate you.

The hash is not constant. With public key crypto you can implement a challenge response. Server generates random garbage, send to client, client signs the garbage using priv key, sends it back as a hash that the server can verify using pub key. Another version of this is with shared secrets instead of public/private, by replacing the signature with simply HMAC(secret, garbage) and keep rest of flow same as above.

> With public key crypto you can implement a challenge response.

Or just use a client side TLS certificate to authenticate instead of or in addition to the username and password.