311–320 of 345 posts
Earlier quoted context omitted.
Ok, but if you handle that in the app, it doesn't get invoked for CSS/JS/images/etc requests.
I don't know how you got to this being used for an app, but in most cases users will just be using a normal web browser and they will be requesting those resources (perhaps with etag/if-modified-since) on each request.
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…
Earlier quoted context omitted.
The first implementation was Bellovin and Merritt's Encrypted Key Exchange in 1992. In 2000 a provably secure implementation was released. PAKE has been around for quite some time and is proven, and is in wide use in the field. Here's a decent article on the subject: https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
I don't dispute the technology exists - I dispute that this technology can be deployed on a web app to general users effectively. I don't believe that is currently possible in production effectively in a way that neutralizes my arguments that an attacker could just change the JavaScript to record passwords somewhere.
Surprise of 2022: you get to the top of HN by telling the world about HTTP Basic Auth ...I am getting old ;-)
Earlier quoted context omitted.
Zero knowledge proofs protect against the password leaking due to any kind of error from the server. That's not security theater, passwords leak all the time. And the nice thing is that browsers already implement that, no need for Javascript. The bad news is that the UX sucks so much that you just can not use, so it's as useful as it not being there. But digest password authentication protects against nearly none of…
> Zero knowledge proofs protect against the password leaking due to any kind of error from the server. That's not security theater, passwords leak all the time. That's a little confused. PAKE usually still stores a password or hashed password on the server, with the password potentially recoverable by brute force reversing the hash. What it avoids is transmitting a hash over the wire that can be reversed into a passw…
PAKE is interesting mostly because we have some infrastructure for dealing with passwords already, but passwords in any form are not optimal.
My big problem with HTTP basic auth in 2022 (squints at Netgear router) is that in Edge/Chrome 1Password can’t auto complete it. It gets really annoying really quickly.
Earlier quoted context omitted.
> unlike Chrome 49, which is the last version for XP and Vista Oh God.
Agreed. My sympathies that the GP even needs to know this.
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…
Is there any chance to go even further than this? I'm imaging a public key based authentication scheme. The user submit their public key to the server first, then in the feature logins, server will generate a challenge for client to decrypt and respond. Of course the browser can apply some UX magic at the client end, for example displaying a pop window to allow user to select a public key for the authentication proce…
In Firefox you can find them here: Settings -> Privacy & Security -> View Certificates -> Your Certificates
Earlier quoted context omitted.
> 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…
> At this moment I'd like to be careful and distinguish between between a technicality (that I'm not even sure I agree with, hashing is still hashing also if you do it a million times) and what the people you're replying to were talking about. Sure, if you ignore what the topic was above then you can indeed say that nobody was trying to avoid doing hashing.
You can cache password validation without storing the clear text password. That’s what I’m saying. If you don’t understand what a key stretching function is, the whole concept makes no sense, so I put a short explanation in.