Using HTTP Basic Auth in 2022

Post by forgotmypw17 » Sun, Jan 02, 2022, 12:24 AM UTC

zinekeller wrote: post #33

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…

> There's one Chrome release, I think 65.x, which screws it up when used together with gzip and requires a page reload after authenticating Fortunately, that Chrome version is dead in the water (unlike Chrome 49, which is the last version for XP and Vista)

Post by hnick » Sun, Jan 02, 2022, 12:40 AM UTC

armchairhacker wrote: post #185

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…

idk if you even need a zero knowledge proof. Server sends client a salt, client hashes the salt and password and sends back to server. Implement this as a built-in feature of the web browser, and the browser can show a special icon or symbol to mark that the password will be sent hashed (and later show a warning on password fields sent via plaintext).

Post by hnick » Sun, Jan 02, 2022, 12:48 AM UTC

lukevp wrote: post #93

jeofken wrote: post #34

Earlier quoted context omitted.

Implementing magic email sign in links is more straightforward and secure. You implement a login route which takes an email address. You symmetrically encrypt the email with a secret key from an environment variable, and send a link to /login?secret= . This route handler checks that the ciphertect decrypts into the email, and if true, save the ciphertext as a cookie and check that it decrypts to the right email every…

So anyone who compromised the cookie can login as this user forever? There’s no expiration or revocation in this protocol. Once you layer on expiration, this is basically sending someone a link with a JWT in the get request. Or you can hit the DB to check a secret key that’s in the email, and if it has expired, but this is worse than JWT because it requires a DB to verify the identity, where JWTs can be verified with…

Post by hnick » Sun, Jan 02, 2022, 12:52 AM UTC

geenat wrote: post #228

Easiest way to defend against brute force attack? How does one rate limit? The only thing putting me off using HTTP auth is this. Seems like you need NGINX configured to hold state and be the rate limiter.

Post by Aeolun » Sun, Jan 02, 2022, 1:06 AM UTC

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…