> 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.
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 hope this has answered your questions.