It's definitely not equivalent. The plaintext isn't (as easily) recoverable, which means that if the user used the same plaintext password for another service it's (somewhat more) protected.
Pass The Hash is also protocol specific - if you try to replay a hash to your average HTTP service it won't go "oh, it's already hashed, thanks" it'll just hash it again and you'll fail to authenticate.
> Then just add a time sensitive seed to it? I don't think it is equivalent to leaking plaintext. It can't be used to guess passwords on other websites.
You're reinventing password hashing and salting. Further, there's no guarantee that the has cannot be used to guess passwords on other sites. For what benefit, exactly? Your hash is now the password, and basically as dangerous as it was in a more conventional arrangement.
Pass-the-hash is a real kind of vulnerability that has been used to exploit real systems. We might be better off sticking with design approaches that don't have this problem instead of trying to fix out way out of the problem.
> If your SSL layer is compromised, you can't trust the client-side encryption. The attacker can send arbitrary javascript.
Are you sure this is what it's guarding against? A sophisticated application architecture might involve a load balancer decrypting and doing the initial routing, several sets of data handoffs, and then the application that needs it handling the password. Any one of them could mishandle or leak the password, but only the one at the end actually needs it in the clear.
How exactly is asking for my password to be hashed "reinventing password hashing and salting"? Seems like the opposite, no?
If your password is properly salted, it can't be used to guess passwords on other sites, that's the whole point of salt and hash.
The fact that RSA is being used means that your plain-text password is going to appear on their servers. Maybe it won't get cracked in the SSL layer, but it is still there.
> Are you sure this is what it's guarding against? A sophisticated application architecture might involve a load balancer decrypting and doing the initial routing, several sets of data handoffs, and then the application that needs it handling the password. Any one of them could mishandle or leak the password, but only the one at the end actually needs it in the clear.
Do you realize that if an adversary even only has read access to the SSL layer, they can just copy the cookie and steal the account that way?
> How exactly is asking for my password to be hashed "reinventing password hashing and salting"? Seems like the opposite, no?
You've already started to add new things, like a TOTP-ish element, to stymie replays. Then the server has to check what it's been fed, having stored neither the original password nor the hash of the password it's been passed. It cannot be allowed to have the hash because the has is now the password. It need something safe-ish to store that the input can be computed on to make comparisons possible.
Now you have all the problems of server-side hashing and comparison coupled with extra client-side hoops.
Again, what have you gained?
> Do you realize that if an adversary even only has read access to the SSL layer, they can just copy the cookie and steal the account that way?
You are absolutely correct. That is completely accurate in every single possible way.
Do you think that perhaps there might be other reasons to consider here? Such as debugging, logging systems, and so on? Perhaps there are design goals beyond blocking direct attacks. On an average day, most of these systems will be more likely to be accessed and used by authorized administrators than by external adversaries, after all. Many security incidents arise not out of malice, but out of tools behaving dangerously. I know I've dealt with sensitive material leaking into logs.
I hope I have made myself clearer. I can see I failed to communicate effectively previously. Please, don't hesitate to say so if I have failed either there or in understanding your points.
> You've already started to add new things, like a TOTP-ish element, to stymie replays. Then the server has to check what it's been fed, having stored neither the original password nor the hash of the password it's been passed.
I don't see how this is any different from Valve "reinventing" SSL by using RSA. This isn't a new concept or roll your own crypto. I just don't want my password to be in plain-text. The only thing the server should get is the hash. If you are using RSA on the password, that means your password is going to be in plaintext on their servers eventually.
> It cannot be allowed to have the hash because the has is now the password. Now you have all the problems of server-side hashing and comparison coupled with extra client-side hoops.
The original password? Ok go ahead and encrypt it (and also hash it). But only do it once and not every login.
> Do you think that perhaps there might be other reasons to consider here? Such as debugging, logging systems, and so on? Perhaps there are design goals beyond blocking direct attacks. On an average day, most of these systems will be more likely to be accessed and used by authorized administrators than by external adversaries
It just seems strange to me that you would have trouble trusting your administrators to accidentally leak logs. What happens if they need to debug or log the app server behind the SSL layer? How likely is it that the dumb SSL termination layer is causing a problem and not the app layer?
You'd actually end up hashing it twice. Once using the salt to go from plaintext to what the sever has stored and then again using the challenge.
It has problems though. The strength of your password hashing would be limited by what the weakest client could do, rather than what the server could do. Asymmetric encryption ends up being simpler.
https://en.wikipedia.org/wiki/Pass_the_hash