251–260 of 345 posts
Earlier quoted context omitted.
> 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. You don't even need the basic auth for that. Years ago I needed to expose my pfsense WebGUI on the default HTTPS, but I didn't want it to be so obvious, so I made a couple of HAProxy rules, which allowed me to open https://pfsense.tld/open-sesame to set a cookie, after whic…
Kind of like “port knocking” but for HTTP.
Earlier quoted context omitted.
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).
Could that really work? Sounds like it's highly abusable if someone compromises the database and gets a list of all the hashes. Now, they don't even need to use rainbow tables or any brute force to compute the password. They just send the hash to the server and will be logged in.
The point is that a malicious or badly-secured site can't use your password on other websites, because ultimately most people use the same password on many different sites.
Earlier quoted context omitted.
Plenty of very simple web apps terminate TLS at the edge ie: at something like API Gateway. So if you then turn on request logging... voila. Hardly a complex scenario, happens all the time. Or at the application layer: @path("/login") def login(request): print("I have a bug, I'll just log the whole request real quick to see wtf is up!", request) It's actually very hard to ensure that the password doesn't get logged.…
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.
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 is https://datatracker.ietf.org/doc/html/draft-yusef-httpauth-s... but looks like it had never gained any traction.
And most likely won't, because browser vendors seem to be extremely reluctant to do anything but deprecate all those standard UIs in favor of messed up JS APIs.
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…
The hijacking of HTTP status codes by client-side apps wanting to interpret them in their own way makes me think we need a new range of codes for user-defined statuses.
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…