There is zero downside to doing an extra hash, except the chance that someone codes such a basic thing wrong.
But only if neither site uses salt, so salt all your hashes. (Not even a salt is necessary here, just a site-wide addition would be fine. Or honestly you could just use a hash that wouldn't be used by a site too dumb to salt their database.)
I can't see a reason why this hurts, but it's probably not worth it. The only benefit I can see it having is if the user reuses their passwords on other sites, as now a potential malicious MITM would have to brute force the client side hashed password in order to reuse it on other sites. They would still be able to use that client side hashed PW to authenticate to the service in question, though.
Basically, hashing on the client does absolutely nothing for the security of the transfer or storage of the password. Whatever the client passes to the server, whether it's hashed or not, is effectively their password, and intercepting that (again, whether hashed or not) would give an attacker the actual credentials of the user.
If you want secure password transfer, do not construct a ghetto solution with stacked hashes, but use a proper protocol like SRP (which, again, is pointless unless the client is trusted).
Especially in the case of Twitter, doing this provides absolutely nothing in respect to credential confidentiality as both sites of the transaction is written by Twitter.
Passive sniffing requires the same attack vector, and the idea of an attacker only utilizing passive attacks makes no sense.
The point is that additional hashing designed for the premise of "broken TLS" fails the thread model test: It is pointless, as the only time it is applicable is when everything is fallen apart.
"Assuming an attacker has broken TLS" - this makes no sense. If I had broken TLS, I could send you a login form with no hashing. I could modify your legitimate API requests, without the need for your credentials. I could take your token and forge requests as I wanted. All your assumptions go down the drain, as the security relied on the presence of TLS.
Basically, making this setup is generally harmful, while only providing negligible benefit in a doomsday scenario where all bets are off regardless.
If you truly want to have better security, you need an entirely different system. E.g., local private keys used to sign requests, or a proper password exchange/validation protocol. Smacking another hash on top does nothing good, and the idea is a good example of why normal people shouldn't crypto.
I agree with you on the general pointlessness of client hashing, though, and oh what a world if we had pub-priv keys for authentication instead of passwords...
The main issue is that security analysis is non-trivial due to the interaction of their security guarantees. The end-result is effectively a new hashing algorithm. Figuring out the properties of this new algorithm requires a new cryptoanalysis (which is more than just avalanche tests).
> It also flies in the face of common in-practice schemes (pre-bcrypt) like doing n rounds of sha256. There should be no real problem with doing the first round on the client.
Old practices are deprecated for good reason, primarily due to flaws. Looking at what we used to do it not that useful.
The main problem is that it's not just "n rounds". The hash on the client must be salted, and it must be salted uniquely for that credential set, and must use a different salt from the backend hash. Plenty of ways to mess this up, and that's before we're even consider the implementation details of salting.
Then comes the interactions between likely different hashes. All in all, it's pretty complicated.
> I agree with you on the general pointlessness of client hashing, though, and oh what a world if we had pub-priv keys for authentication instead of passwords...
Especially with the only sensible procedure being password managers, it's silly we don't have asymmetric authentication. :(
If it's true, the attacker just has to do additional hashings to crack the password.