> 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?
> I don't see how this is any different from Valve "reinventing" SSL by using RSA.
What Valve is doing is layering cryptography to make it possible to do access control more granular than a pure binary. What you are proposing is layering hashing in a way that does not introduce access control.
I hope this is clearer!
> 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.
OK. Now your hashword is on the server. Your hashword now has essentially all the properties of your password that you were trying to get away from in the first place. It is de facto your password now.
Sure, it's a different string now. Your goal is accomplished and the server doesn't have your magic string. Instead it has a different one that's equally magical, equally came from you, and equally security-sensitive.
That's why pass the has was brought to your attention. Network security has been down this road before. We had login systems where the server only ever had a hash, and never the original magical string. They were not safer.
> The original password? Ok go ahead and encrypt it (and also hash it). But only do it once and not every login.
OK. So now we have a new thing that's identical to a password in all of its properties, except that it requires extra work client-side. Again, what have we gained? This is not an idle question, it's the only one that matters.
Valve has an answer, and it's a reasonably compelling one that speaks to real-life use-cases.
> It just seems strange to me that you would have trouble trusting your administrators to accidentally leak logs.
I routinely see developers do things like dump full web request contents into logs without thinking about consequences. With that in mind, I think it's very possible that exactly this kind of scenario could happen. Indeed, I think it a virtual certainty.
The plaintext of passwords being stolen from the memory of servers that handle logins is a comparatively uncommon event, as far as I know.
> What happens if they need to debug or log the app server behind the SSL layer?
A great question! That's critical info. In this scheme, they can. They just cannot access the most sensitive contents, such as passwords. Literally every other part of the request has been decrypted and is available for use.
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?