I'm assuming it's more that they used to support logging in without SSL, and they just never saw a reason to put in work to change the login to get rid of extra security once HTTPS became mandatory.
Except that without SSL, some JavaScript could be injected to grab the password completely outside of the RSA encryption. So assuming there is already a MITM who wants the password, all you'd be doing is making his attack slightly more complicated.
The passive collection case is presumably enough to justify it. Like, after those folks who were sniffing Facebook and MySpace cookies on unsecured WiFi routers were caught, I can imagine pushing for something like this, "just to force them to single us out and perform an active attack on us, which most passive WiFi sniffers are likely not willing to do," or so.
Another separate derivation would be: “we log every single call. period. I will take on whatever cost to have that oversight of my system.” Well that's problematic, dr. boss, because several calls have PII in them and we want to be careful with how we store that. "OK, we encrypt the PII in-transit so that our logging doesn't have access to it." Well OK but our “log everything” philosophy is now also logging the keys that it was encrypted with, which the client has to fetch. Every call, right? So we are still storing the PII for any hacker to decrypt. "Well, let’s use asymmetric encryption so that this information is not sufficient to decrypt.” OK, but I can still connect information about how you were playing this game at this time, to how you were playing that game at that time. The logs contain that second-order PII that exists in correlations because you use a deterministic process to encrypt. (And at this point the obvious thing to do is a nondeterministic encryption process but you can also just rotate the keys periodically to make this sort of correlation only work over very short timescales.)
Just saying, HTTPS assumes that the problem is insecure channels between secure endpoints when the problem can also be at one or the other endpoint. Like another person said, you might also decrypt right before a load balancer and then route the sensitive data to some other data center because it has lower overall load, etc. etc.
Disagree. Theres a big difference between passive and active collection attacks. If the stakes are a site-wide password breach, it can make sense to eliminate passive attacks specifically.
Remember, sometimes breaches are caused because someone at the POP left HTTP parameter logging enabled.
Support logging without SSL meaning the backend accepts it, not that the login page is ever served like that. Remember that they have desktop and mobile applications for various platforms, where the signing would be part of the application. Although the keys...
> Except that without SSL, some JavaScript could be injected to grab the password completely outside of the RSA encryption. So assuming there is already a MITM who wants the password, all you'd be doing is making his attack slightly more complicated.
An SSL client will cryptographically verify the authenticity of all messages recieved from Valve's servers, so the resulting webpage can't have any Javascript injected by someone without Valve's private key.
Without this kind of authentication, encrypting the connection would be pointless.
the assumption is that the javascript would be injected into the page on its way from steam servers to your browser. ssl would prevent that. i think you're imagining a case where a user has (for example) installed a malicious browser extension. ssl would not help with that.