1. 37

  2. 6

    So even if a third party could sniff every bit of their data as it was sent to and from the Steam servers, they would at least have no way of knowing their password — at least not without vast computational efforts.

    If someone can do MITM, they can also replace the public RSA keys sent by the server with their own. Presumably this only protects against passive MITM attacks.

    1. 4

      That is kind of interesting, but not in the way I expected. Like the author, I can only speculate, but I wouldn’t be surprised if it wasn’t just the case that Steam felt TLS wasn’t secure enough but that someone thought it would be a fun project to harden login even further and because it’s Steam, why not?

      1. 9

        It protects the password from network level SSL (passive - an active MitM could provide a fake public key or serve a compromised rsa library) interception employed by AV tools and ad frameworks (like that Lenovo superfish cert a few years back)

        I have a feeling that Steam’s target audience lives in that dangerous group of people who are capable of installing whatever crap they want, who are also not versed in security enough not to do so and who have a very valuable asset (the steam account with all games)

        Any bit of additional protection helps at that point

        1. 1

          That’s kind of a funny threat model, but why does Steam not just do CA or cert pinning like a lot of mobile apps do nowadays?

          1. 2

            They do. But they also offer a website where people can log in. And they offer OAuth “login with steam” services, all of which happening in browsers and not supporting cert pinning

            1. 1

              Ah right, the browser. I wonder if they’d have done this if Chrome was market leader back then.

          2. 1

            I’m not quite grasping the threat model you’re trying to show.

            Passive SSL MITM isn’t, someone has to encrypt with a new cert – either your network administrator because all your traffic goes through a MITM proxy, or software on your box. But for that to work your machine already has to trust a non-standard CA root, which means your adversary already did something arbitrary on your box.

            So in that world what does an extra layer of RSA get you?

            1. 1

              I imagine the point pilif was trying to make is that it’s not outlandish to consider users who’ve unwittingly allowed a malicious CA root and new cert on their machine. So, security in layers. That said, anyone who has done so is effectively vulnerable to mitm attacks on every website they visit and probably reuses their password, so their steam account might as well be considered compromised.

        2. 3

          To add to the speculation: an attacker gained access to a Steam database containing “hashed and salted passwords” in November 2011 - perhaps they changed their password storage (and login) mechanism in response to that incident.

          1. 2

            Steam’s login method is a precursor to what is being standardized by the IETF under the name OPAQUE https://tools.ietf.org/html/draft-irtf-cfrg-opaque-01: a browser-side authentication technique that makes it possible for the password to never leave the browser, not even during the registration phase.

            The OPAQUE Asymmetric PAKE Protocol


            This document describes the OPAQUE protocol, a secure asymmetric password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the core OPAQUE protocol, along with several instantiations in different authenticated key exchange protocols.

            1. 3

              SRP is a precursor to OPAQUE. Simply encrypting the password with RSA is… ehhhh not really.

            2. 1

              Back around that time there were a lot of e-commerce shops running software called Actinic (which has at some point in the time since I last used it been bought and suffered from synergy.) This software ran as a windows application in to which you could add all your stock details, images, etc and select from a handful of e-commerce templates, and/or modify/create your own.

              From that local database it could generate a static website with a handful of cgi scripts and upload it to your host of choice (while they would prefer you use their service.) None of the Actinic e-commerce websites I saw used https but all handed purchasing and most handled payment collection within the website itself. How was that done securely you ask?

              As far as I could tell at the time, the card details form had some js that would encrypt the input and post it to the cgi script which would then store in a txt file. The Actinic desktop software had a sync button that once pressed would download any pending orders from the website, to which you would enter the card details into your card machine manually, print off the receipt, pack and ship the lot off to the customer.

              The one I worked on got quite popular, so much so that we “invested” in a third party card processor which acted a lot like paypal in that the shopping cart would redirect the user to the third party payment processor, they would using https collect the payment details and charge the card before redirecting back to the cgi script with the status.

              TL;DR For the majority of the time I worked there their e-commerce website worked without https.