How do you send a password over the internet? You acquire a SSL certificate and let TLS do the job of securely transporting the password from client to server. Of course it’s not as cut-and-dry as I’m making it out to be, but the gist of it holds true and stood the test of time. This hasn’t always been this way though, and one incredibly popular storefront on the world wide web prefers to add a little extra to this day. I’ll be discussing Steam’s unique method of logging in their users, and go down a deep rabbit hole of fascinating implementation details.
Not exactly my cup of tea, but if there’s one thing I’ve learned over the years here at OSNews, it’s that the most obscure stuff can generate a lot of interest. So, here you go.
Browsers send passwords the same way as any other input fields and assume the transport layer encrypts it. Although widespread, this is not a great practice because it allows the website administrators to see the password and believe it or not this isn’t ideal. It’s better that the password be hashed and that not even the administrators can see it, and when I first glimpsed this article this is what I thought they were going to do. But no, they’re just applying RSA encryption.
As to why…well one problem with SSL certs is that we place a lot of trust in the CAs that sign them, some of which have broken this trust in the past. And while they’d probably never target Steam’s service, in general a certificate authority can conduct a successful man in the middle attack pretty easily (and using bog standard software like “squid”). So by relying on SSL, websites put the security of their user data in the hands of certificate authorities that we hope are trustworthy. Even CAs that are genuinely acting in good faith can make mistakes and some certificates have been granted for fraudulent parties.
By using their own encryption inside the SSL/TLS tunnel they make it harder still to get the data. But assuming the man in the middle attacker is able to modify contents in addition to simply decrypting it, they can technically use their access to replace steam’s RSA key with their own keys…so while it’s more difficult, it’s of limited benefit.
I’m not familiar with it, but my guess is that it may be a simple case of the steam client already using their home built RSA protocol. Then when they added the ability to login via the website they decided to keep the same authentication infrastructure/APIs and porting their RSA algorithm to the browser. So all this may have been done this way simply to be compatible with the steam client.
If you hash the password on the client side then you run the risk of making the system susceptible to hash passing attacks. At which point the hash becomes the password, and effectively nullifies any benefit from storing the password in a hashed form.
You also get locked in to a single hashing algorithm, as changing it server side also requires changing every client.
As you point out, Steam’s method is mere obfuscation and is still dependent on the transport layer. An attacker who compromises the transport layer can still perform a MITM attack, they just have to work out how to intercept the key and insert their own known key in the middle.
There are however significant downsides to obfuscation in this way.
The system is more complex so harder to debug and more likely to break, while providing little/no benefit.
If you are performing vulnerability scans, vulnerability scanners will not know about this system and either require significant custom code to handle it, or will return false negative results.
The same goes for manual testing, if you are hiring consultants to test the system then they will use chargeable hours to reverse engineer this obfuscation before they can start testing the actual backend. The end result is either that the testing costs more, or the coverage is reduced.
I’ve encountered many such systems, some basic obfuscation resulted in all previous vulnerability scans giving an empty report. Once i worked out how to bypass the obfuscation, there were vulnerabilities galore including some very simple stuff. Usually simple vulnerabilities are quickly found by scanners and fixed, but in this case the obfuscation had hidden them and they went unnoticed for a long time.
bert64,
I understand that, when a hash becomes your key, your hash can still be copied by internet snoopers if it is transmitted in the clear, but it should not be transmitted in the clear! It is still considered bad practice to use/transfer passwords without hashing though because it gives employees access to raw passwords which may be used to compromise a user’s unrelated accounts (users often reuse passwords). Hashing means that if the database is hacked or the network is tapped only the hashed password is compromised.
As for adversaries working on the inside, granted they may have access to the hashes, but if they do they are likely to already have access to customer data. Consider this: as technical staff it’s usually irrelevant to me whether I have client’s passwords / hashes or not since I already have lower level access into the systems. I’m already inside and don’t need customer passwords/hashes to help me get in. If my employer did NOT trust me to keep customer accounts safe, then frankly they should NOT trust me on internal networks and databases either. In short, yes there is a risk of rogue insiders, but it’s not made any worse by using password hashes and is still safer than using raw passwords.
For even better security obviously you wouldn’t use a password at all but a private crypto key instead, which is very effective. Browsers even have basic support for client keys. However the usability challenges are barriers for typical users, which is why we still primarily use passwords.
They don’t need to change often and it’s still safer than sending a raw password.
Yeah, I don’t know what the steam client does for encryption. Could be SSL/HTTPS, no clue… but I suspect that’s where this login method actually came from and it wasn’t created for the web login originally.
I really love this answer. I used to be a software developer. I now work in security.
You really need that higher level approach to things to think of all the downstream impacts. I’ve grown to loathe these complex obfuscation mechanisms. Either you end up reverse engineering it or you get the team to disable it temporarily. Both of which are bad options.
That said, if they do simple things to obfuscate, I think it can have some value.
For example, I think it’s reasonable to ‘salt hash’ the user’s password client side so the user’s password is not transmitted in clear text on the internet. I know the salt hash would have to be known public for it to be used client side. It also makes it so if someone uses the same password on two different sites, the sites see different passwords.
You’d still ‘salt hash’ it again to store the password in the database, but this time with a private salt.
It’s simple obfuscation and would not really hinder many downstream systems.
Yamin,
Quite right. Obfuscation not provide strong cryptographic defense and may be merely an annoyance to a real hacker. But still the fact that obfuscation breaks automated scans does help add barriers for the so-called “script kiddies” who depend on automated scans to identify targets and infiltrate networks.
Something as trivial as renaming a wordpress admin pages – something that obviously has zero cryptographic value – can be enough to throw most automated wordpress attackers off the trail. I see opportunistic attacker scans in the logs frequently on production websites. Having the attacker’s scans fail because they used the wrong url can provide more protection against zero day exploits for the simple reason that hackers are too busy to hand craft attacks against sites where automation failed.
Yep, that’s exactly why we use salted hashes. Also because salting helps defeat efficient brute forcing and the use of large rainbow tables.
I recall looking at the LiveJournal login page a long time ago and it did some sort of challenge-response hash computation on the password in JavaScript, stored the result in a hidden field, and cleared the password field before submitting the form. It would still work submitting the form with the plaintext password if you had JavaScript disabled. This was long before HTTPS was common; there may have been an option to use an HTTPS login page, but I don’t think it was default.
“I’ve encountered many such systems, some basic obfuscation resulted in all previous vulnerability scans giving an empty report. Once i worked out how to bypass the obfuscation, there were here vulnerabilities galore including some very simple stuff. Usually simple vulnerabilities are quickly found by scanners and fixed, but in this case the obfuscation had hidden them and they went unnoticed for a long time.”
Exactly the same experience I had too.