> A compromised website that was well designed
Ah yes, "if nobody makes any mistake there's no problem", that's worked so well forever hasn't it?
> Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that.
That makes quite literally no sense, did you miss the entire thing and go off with whatever?
The request here is to make the browser's support for HTTP authentication better. The entire point is that there is no "quick code edit" without owning the entire browser at which point you're quite thoroughly owned anyway.
Re:Using HTTP Basic Auth in 2022
by garbagecoder on Saturday January 01, 2022 @04:57PM
(#29763278)
I don’t think he understands salts or really hashing at all and this is messing up the logic in his posts.
Re:Using HTTP Basic Auth in 2022
by garbagecoder on Saturday January 01, 2022 @04:56PM
(#29763262)
If “should” were a word that meant what people thinks it means, we wouldn’t need security at all.
A compromised website that was well designed should not leak your password any more than a client-side hashing implementation. This is because the passwords are hashed in the database. Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that.
And credential stuffing? Client-side hashing does absolutely nothing to prevent credential stuffing other than that you may need a GPU to do a lot of hashes quickly. Client-side hashing doesn't make a server handle more or less authentication requests.