12 ms·

Steam's login method is kinda interesting

523 points by zertrin 6y ago

noobquestion81 6y ago
If you are wondering why they do this, the answer is not because they don’t trust TLS. It is (likely) because they use geographically distributed terminating load balancers, perhaps owned by someone else or run in someone else’s POP, and are trying to prevent passive collection of passwords.
- gruez 6y ago
  I guses that works, but it only really prevents surreptitious password collection. If you're in a position to do active attacks (eg. MITM), you can just substitute their public key with your own.
  - lights0123 6y ago
    For sure, but it's at least possible for them to set up a honeypot to detect that.
    - gruez 6y ago
      Yeah that prevents mass surveillance but doesn't prevent targeted surveillance (think steam account with valuable skins).
      - noobquestion81 6y ago
        The stakes are “we lost all the user passwords”. This is a problem that can occur if e.g. the POP is logging too many things. Preventing passive collection at POPs also prevents all sorts of footguns like these that can lead to a breach, it is smart security sense IMO.
  - est31 6y ago
    You might be "only" admin of such a MITM box and can maybe only see/search the decrypted contents but not alter them.
- nijave 6y ago
  This would also cover intercepting proxies like many corporate networks have and potentially protect against less technical malware that installs MITM proxies on the local computer and root CAs to intercept local traffic (not sure if this is still a common type of malware on Windows computers but I've seen it before)
- mminer237 6y ago
  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.
  - jaywalk 6y ago
    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.
    - mlyle 6y ago
      Those geographically distributed SSL-terminating load balancers could still conduct such an attack, SSL or not.
      - jaywalk 6y ago
        Yep. If any sort of MITM attack was their motivation for this, they didn't really think it through.
        crdrost 6y ago
        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.
- yuliyp 6y ago
  It also potentially protects the passwords from their web servers if they implement it like that. They can pass the encrypted password to a separate service that has the private key and decides to give you a session or not.
- deleted 6y ago
  [deleted]
RexM 6y ago
World of Warcraft also uses SRP for logging in via the game client. Or at least they did when it was originally released, I don't know if that's still the case.
Cthulhu_ 6y ago
I've heard about the security of a mobile banking app about eight or so years ago, when mobile banking was still very much a new thing and trust was a big issue. They too opted to write a second encryption layer on top of TLS / SSL, fearing MITM attacks. That was also when iOS didn't support SSL pinning yet. It seemed to work for them, security researchers went to town on it and while they quickly discovered there was a second encryption layer below SSL, they were unable to determine what it was and how to crack it. IIRC their encryption was never broken, and thanks to that track record, they slowly increased daily spend limits over the mobile app. Long term, because they were very forward-thinking and they had competent native app developers (as opposed to the competition who struggled for years with mobile web / crossplatform tech), they increased their market share by a lot, now being the largest bank in NL; can't find historical data, but they went from 37% in 2016 to 40% in 2018.
- lol768 6y ago
  There was a UK retail bank that tried a strategy like this. I maintained (and still do maintain) it was security through obscurity and a waste of engineering effort that should've been spent on actually hardening the banking API server and migrating it to a modern stack. I thought it inevitable and indeed - it got cracked twice anyway (despite the use of Arxan, extensive anti-debugging functionality and rewriting the crypto on at least one occasion).
  - sjtgraham 6y ago
    Barclays? Was cracked both times by me :) Disagree that hardening the API server is any better. This is the approach common in the US market, and my team has broken everything available there too. Also disagree with insinuations that these banks don't have good, modern stacks. Barclays in particular is great. Way better than any challenger bank. Lloyds also took a similar approach to Barclays but they did a better job than Barclays did (although Barclays did a great job themselves too) and so we never got around to finishing it before we pivoted to the US market. As far as I know it's still unbroken, although I'm pretty sure my colleagues could easily break it today. We've since developed far more sophisticated reversing techniques.
netsharc 6y ago
Yahoo! Mail also does (maybe "did", I looked at it a decade ago) something similar. When the user opens the login page, s/he gets a random string in one of the hidden form fields, IIRC it hashes the user-entered password, and then adds the random string and hashes it again, and sends this result to the backend. On the backend, it knows the random string it sent to the user, and it has the hashed password in its DB, so it can do the same algorithm and compare the results.
- k1t 6y ago
  The danger with that approach is that the hashed password has become the password. If the hashes are leaked, they can be used to login.
  - lostmsu 6y ago
    That only works if the string is the same each time. But it won't, if it changes like TOTP code.
    - jarkhen 6y ago
      If the string changes each time, how could they possibly have the matching hashed password stored in the database?
      - fgonzag 6y ago
        They have the users password hash stored in their db so they can replicate the process server side: login_token = hash(pwd_hash + nonce) its nothing too wild, especially considering the age of yahoo mail.
        jarkhen 6y ago
        Ah, right, I misread the original description of what they were doing. As is, then, it really is just making the hashed password the new password. If I can get the hashed password out of the DB, I can load the login page and simply skip the initial hashing step that's done on the frontend. I now have access to the account without ever knowing the original password.
thoughtsunifi12 6y ago
delete thoughtsunufic account
simongr3dal 6y ago
I’m just annoyed that Steam still doesn’t support standard TOTP two factor but uses either an email code or their app.
- kuroguro 6y ago
  If you root your phone you can get the secret out and use it with regular TOTP software that implements that variant (I forgot the name - I just know Bitwarden supports it).
  - pzmarzly 6y ago
    There are some desktop implementations of Steam TOTP client, so you don't even need a rooted phone, as long as you trust some random open source code. https://github.com/KeeTrayTOTP/KeeTrayTOTP#documentation https://github.com/KeeTrayTOTP/KeeTrayTOTP#documentation
    - kuroguro 6y ago
      > In the case of Steam Mobile Authenticator the new output format was reverse engineered by various developers Oh, so it was a custom one! Was convinced that it was a less used standard algo.
- fuzzy2 6y ago
  Not just that, I just noticed that the Steam app does not support iPhone backups. Blizzard app does, as does the Verisign VIP Access app. Pretty lame. The restore SMS didn’t arrive on time either that evening, fun!
aasasd 6y ago
I keep being somewhat baffled by Steam's login process every time I'm forced to go through it. Apparently Steam is such a cesspool of (pre)pubescent teenagers, with rampant account hacking and theft of funds, swag or whatever, that they feel the need to fortify the process if only to make it more inconvenient for the hackers. - “Remember the password” barely ever works, even on desktop. Since I don't quite log in every day due to being too old for that, I have to redo the process every time—on a machine that I bought with my own money just for myself and intend to protect with both technical means and physical force. - Somehow copy-pasting passwords from KeepassX/XC doesn't work on Mac, with the shortcut. Not sure if this is a misfeature of Steam, but I have to paste the password to an editor first and then copy out of there into Steam. (Seems though that ‘paste’ in the context menu does work—this might've changed since I first noticed the issue.) - And of course, the weird variation on 2fa, via email, instead of the good regular TOTP. As is tradition by now, I'm also given the choice of installing yet another app on the phone, which somehow doesn't quite seem to serve my interest.
- Nullabillity 6y ago
  FWIW, the app uses a variant of TOTP. Some TOTP apps (including one for Yubikeys[0]) support generating them if asked to. [0]: https://github.com/Yubico/yubioath-desktop/issues/72 https://github.com/Yubico/yubioath-desktop/issues/72
- blackearl 6y ago
  How often are you logging into Steam? The app stays logged in for me pretty much forever
  - dfabulich 6y ago
    I have the same issue. On Mac, I log in to Steam about once a week (sometimes longer than that). I have to login with my password and get a Steam code almost every time.
    - dkersten 6y ago
      Huh strange. I’ve used steam on windows, Mac and Linux over the years and with different frequencies of use and still only ever have to manually log in once every few months.
bArray 6y ago
One reason not to trust TLS is that it's one system that you want to be secure for all your users - indefinitely. If in the future there was some method to crack the TLS or the appropriate keys/certs were leaked, any recorded traffic could be retroactively cracked. Remember also it wasn't so long ago we were talking about things such as POODLE attacks. For all we know, some bad implementation of TLS 1.3 could default to some crappy easy to crack algorithm. I believe there was a paper (can't find it now) that speculated about the cost to crack a specific TLS setup to be about $10 million USD in processing, going back some years. (I think it was in reference to some half of VPN traffic at the time using the same keys.) If Moore's law still applies in any sense, that cost likely halves every two years and people only really change their passwords if they have to. Another reason is that it reduces risk server side if you are never handling user passwords - at worst an attacker gets a temporary hash that's valid for a short time, specific to that server. Maybe they can do some harm during that time, but you can ultimately revoke that key and undo the changes to the user's accounts.
- sonotmyname 6y ago
  > If in the future there was some method to crack the TLS or the appropriate keys/certs were leaked, any recorded traffic could be retroactively cracked. This is incomplete. TLS does allow for ciphers that enable Perfect Forward Secrecy (PFS) to prevent this. Those ciphers are not the most commonly used ones, but to describe TLS the way you do implies it's a flaw in TLS.
  - johncolanduoni 6y ago
    I thought ECDHE or X25519 suites were pretty common these days; I appear to get the latter when connecting to Cloudflare hosts for example.
  - bArray 6y ago
    > This is incomplete. TLS does allow for ciphers that enable > Perfect Forward Secrecy (PFS) to prevent this. Sure, it was simplified. I can't remember exactly what the support was like for PFS? And given it probably requires additional exchange for DH, I imagine it would be disabled due to resources reasons.
mschuster91 6y ago
> That begs the question why. Why bother creating such a weirdly intricate system on top of something that works just fine on its own? I have my own theory, but keep in mind it’s just that. To avoid admins (or hackers) in enterprise "SSL breaker" boxes from exfiltrating passwords.
- mminer237 6y ago
  How many enterprise admins are trying to get employees' Steam passwords? I think the "it used to support logging in without SSL" theory is more likely.
  - meibo 6y ago
    I wouldn't call it an impossibility, Steam accounts often carry a real, huge amount of value to their owners, going into the thousands of dollars of either games or trade items. Even if it wasn't the main reason, it probably played a role. Some small time admins in education facilities would probably have an easy time with this stuff and wouldn't get caught doing it.
txr 6y ago
This exact procedure is used for the pidgin plugin: https://github.com/EionRobb/pidgin-opensteamworks https://github.com/EionRobb/pidgin-opensteamworks
madisp 6y ago
The 3600 second + a bit (~1s) is a common thing that happens if your periodic scheduling work is one-shot and repeating is achieved through scheduling the task again after completion. E.g. consider the following code (in Kotlin, but hopefully still readable): fun rotateKeys() { publishNewKey(key = generateKey(), timestamp = now()) schedule(::rotateKeys, 1, TimeUnit.HOUR) } if `generateKey` and `publishNewKey` take around ~1s then you'll observe exactly this behaviour - the timestamps will start drifting from some original value.
- mlyle 6y ago
  Thank you-- I came here to post exactly this. Very easy to get something skewing by a second if, say, the key generation takes a second.
  - xtacy 6y ago
    Or, you could (re)schedule first and then generate the key? Assuming that key generation doesn't take an hour, of course. :)
    - madisp 6y ago
      Ideally you'd use something modern that invokes your function every hour (cron? :P) so that the rescheduling is detached from the function. I think if generation takes X hours of raw CPU computation where `X >= 1` then as long as you've got C cores and `C > X` you should be OK?
      - hatsuseno 6y ago
        Out of curiosity, why is having the process scheduled tightly with (something akin to) cron ideal to you? atd is, to me, a perfectly reasonable alternative. I guess it depends on the environment a developer finds themselves in when implementing the feature. It might just be easier to setup the next scheduled job than implementing cron-like features in the system that does the executing of scheduled junk.
    - 6y ago
qorrect 6y ago
> The internet was a different place though in the early 2010s Oh how far we've come. /s
- Taylor_OD 6y ago
  Uber didnt exist in early 2010.
  - qorrect 6y ago
    Pirate Taxi's have existed for decades, the mobile app for them did not yet exist.
syoc 6y ago
There was some discussion on /r/netsec where this was published as well. https://www.reddit.com/r/netsec/comments/ksn6rc/steams_login_method_is_kinda_interesting_rsa/ https://www.reddit.com/r/netsec/comments/ksn6rc/steams_login...
BlueTemplar 6y ago
I wonder what did they use between 2003 and 2012 ?
superkuh 6y ago
It's not listed anywhere on his site but by random guessing of URLs I found his RSS feed: https://owlspace.xyz/index.xml https://owlspace.xyz/index.xml
MayeulC 6y ago
If you want fancy password-based authentication without transmitting it, have a look at PAKE (and OPAQUE): https://news.ycombinator.com/item?id=18259393 https://news.ycombinator.com/item?id=18259393
jordache 6y ago
This is clearly a violation of security good practice tenet of not implementing novel patterns.
throwaway09223 6y ago
Not transmitting the password is good practice for the same reason it's good practice to not store passwords cleartext: systems can be compromised. I trust we all agree that storing cleartext passwords in a database and doing a simple string compare is a problem so I won't rehash that bit. If a login server is compromised then attackers can harvest cleartext passwords. It's the same class of problem with a reduced attack surface. There is no good reason to transmit a persistent authentication secret as part of authentication. Just don't do it.
yuliyp 6y ago
Regarding the rotation timestamps: My guess is that the rotation is implemented as a "generate a new key when needed" rather than a cron: When someone asks for a key to issue to a user trying to log in, try to fetch a cached one. If one is there and it's < 1 hour old, return it. Otherwise generate a new one and record its timestamp.
T3RMINATED 6y ago
zis is a blog by some german nerd.
nirushiv 6y ago
How does this work implementation wise? One private key per application? Per user? Or refreshed on a per-login basis on the first POST?
sroussey 6y ago
Repeat from a couple days ago: https://news.ycombinator.com/item?id=25690995 https://news.ycombinator.com/item?id=25690995
- hutattedonmyarm 6y ago
  I posted even earlier: https://news.ycombinator.com/item?id=25684254 https://news.ycombinator.com/item?id=25684254 But I’m happy to see it got some attention after all!
sroussey 6y ago
I mentioned this on Twitter[1], the reason to encrypt before sending over SSL is not about double encryption, it’s about how a large backend system is designed. Often, you have load balancers that are SSL endpoints, so the data is decrypted at that point. You can start to see the problem already. What if there is a different bug, and so a dev starts logging requests somewhere down the line? You accidentally start logging cleartext passwords. Oops. Facebook was fined for this not that long ago. But if the password is encrypted, then it’s not really an issue, and the black box blob can be forwarded to a login microservice. There, the team decrypting will be on higher alert. So depending on the structure of various teams, you now have fewer teams that need that kind of security oversight and can move faster. Smaller blast radius of something goes wrong. [1] https://twitter.com/sroussey/status/1347688753221931010?s=21 https://twitter.com/sroussey/status/1347688753221931010?s=21
- xwdv 6y ago
  So what you’re saying is if you know what you’re doing and you don’t log any clear text passwords it’s fine to not double encrypt?
  - colechristensen 6y ago
    If you are immune from mistakes, sure. Making decisions as if you are immune to mistakes is a good way to ensure you prove yourself wrong in the worst way. Making decisions to prevent things which should be impossible is how you build reliability.
    - remexre 6y ago
      And, adding assertions / very loud logs is a good way to be sure your assumptions hold: e.g. causing your tests to fail if the test user's password (or other privileged info, etc) appears in any logs is a fairly good extra safety layer.
      - sroussey 6y ago
        That’s a great test idea I have not used myself, thanks! I’m also working on forks of logging systems to make them smart about what they log in the first place, but not quite like the Palantir does it.
cafed00d 6y ago
It's stuff like this that makes me wish for a _version_ of Windows that is completely built & operated by Valve. Or atleast, I wish Microsoft could implement such features for their login interface. I love gaming on Windows & PC and would love to have the PC have a "Big Picture mode" friendly UI, _throughout_ the OS. Some gimmicks I have had to resort to are to set up my PC Sign-In to be _without_ a password and on a _local account_ on my Win10 PC, along with having Steam start in BigPicture on startup. This way I can switch on my PC and have my controller connect to start gaming just like a console; but way better graphics of course :) It's these tiny affordances that collectively add up to great User Experience features.
mxscho 6y ago
Steam and especially CS:GO has a problem with phishing sites (with fake Steam OpenID pages) where attackers (after getting access to the Steam accounts) can automatically create permanent access to accounts by generating API keys to control those phished accounts. This is used e.g. to swap trade offers in realtime, i.e., a trade offer with the actual account is replaced by a trade offer with a bot with a similar looking profile (all set up automatically). All of this is done in the timeframe between the user setting up the trade offer and the actual 2FA mobile confirmation of this trade. People are being phished like this for years and Valve fails to take the responsibility to implement a simple anti automation measure at the part of API key generation (e.g. email confirmation or captcha). The monetary damage done to users is probably in the high thousands, if not millions, at this point in time.
bricss 6y ago
It seems to me that whoever wrote this article has no idea what an MITM attack means.
rvr_ 6y ago
Steam was always a high target for hackers and a low target for law enforcement (who cares about your stolen games?). It makes a lot of sense for them to implement every security method conceivable.
simias 6y ago
Seems awfully complicated, slow and error-prone to use full blown RSA for this. Why not send a challenge token and hashing salt and ask the user to reply with the (effectively one type password) crypto_hash(crypto_hash(salt, password) + token)? On the backend they already have crypto_hash(salt, password), they know the token they sent so they can build the same hash and see if it matches. This way the backend actually never has access to the non-hashed password. The only inconvenient I can see is that you can't transparently rehash on login on the backend if you decide to migrate to a different, potentially stronger hash algorithm later. But then again if the worry is that passwords could leak in the backend, using hashes makes it effectively impossible by construction. I guess nobody gets fired for using RSA. But at the same time doing "serious" crypto in JS always feels icky to me.
- josalhor 6y ago
  I have wondered many times why we still send the password over the wire (even if in SSL). It should be hashed with a salt every time before being sent! A lot of people reuse their passwords, the user shouldn't trust the website to hash it.
  - dfox 6y ago
    Because calculating the salted hash on the client side will just substitute the hash for password and render the whole hashing useless. Also it would require additional roundtrip to server in order to get the stored salt. Then there is the UX problem where mechanism like that would have to be implemented on the browser level (and in fact it is as Authorization: digest is mostly what you are proposing) which according to some leads to “ugly and confusing” UI.
    - josalhor 6y ago
      > Because calculating the salted hash on the client side will just substitute the hash for password and render the whole hashing useless. I don't understand what you mean. Just in case I didn't make myself clear, I don't mean substituting the hashing on the server, I mean adding it on the client. > Also it would require additional roundtrip to server in order to get the stored salt. It could be salted with some constant/domain name. > Then there is the UX problem where mechanism like that would have to be implemented on the browser level What I am saying could perfectly be done with javascript, although I don't see why browsers could not integrate it too. > which according to some leads to “ugly and confusing” UI. I am completely lost, I am not sure if you understood me but I don't understand what you mean. Can you explain yourself further or provide a resource that explains this UX problem you're talking about?
RupertWiser 6y ago
I kept reading waiting for the author to address man in the middle attacks but no mention. This adds no additional security. You can easily provide your own keys or JavaScript and completely bypass this. Like others have suggested, I get the impression this system is assuming TLS will work and perhaps isn’t trusting the server the password ends up on.
- deepsun 6y ago
  There is additional security. It's much harder to modify traffic, not just observe it.
deepsun 6y ago
tl;dr: User client requests a public key from Steam's servers (rotated each hour), and sends passwords encrypted with it.
warpech 6y ago
From the OP > the login page also sources jQuery version 1.8.3 which was released in November 2012 Wow, that's a prime example of "if it works, don't change it"
apatheticonion 6y ago
How hard it is to move to using OIDC with commonly implemented features such as SSO, anomaly detection, passwordless login, app based MFA, etc? It's good enough for major financial institutions and available as a service using any number of providers (like Okta, AWS Cognito, Auth0). I love Valve and Steam but their game launcher client (Steam) lives in the stone age when it comes to use of technologies. That said, it's far better than the competition so I am still happy, but it is still annoying.
spondyl 6y ago
On a side note, I'd like to say I'm a big fan of this blog theme the author has going. It has a kind of homey feel thanks to the owl and the little + symbols in the background wallpaper
g7r 6y ago
This strange solution looks like a legacy of times when Steam used HTTP instead of HTTPS. Maybe they just didn't bother to update working code after migration to HTTPS?
bullen 6y ago
I use single serving server salt and SHA256 hashing for my logins: http://talk.binarytask.com http://talk.binarytask.com
jzer0cool 6y ago
I always had some concerns with desktop apps / mobile apps. Unlike browsers which has a lock symbol how can desktop apps inform whether communication is over tls for example? There is also the challenge that it 'was' tls at one point when you first inspected but could later changed to some non secure transmission without being informed of such change. What might be some solutions to this? I have yet to see anything that is standardized for this purpose. Other than, loosely here, 2fa token for purpose for login only, but is still without knowing whether transmission to endpoint was over secure channels.
gitgud 6y ago
Not sure if anyone noticed, but according to the "login.js" snippet, Steam removes all non-standard ascii characters from the password, before encrypting it... Doesn't that essentially reduce the password's strength? Especially if there's a lot of non-ascii characters in it....
- roelschroeven 6y ago
  I would think so, yes. Maybe they are trying to prevent problems with users logging in from computers using different code pages? Is that still a problem?
asdfsfkwqe 6y ago
In corporate networks, you often need to install a root CA. Thus HTTPS essentially became HTTP for network admins.
ezconnect 6y ago
This is done by bank login page during the 2000s and still being done by my bank and other bank login page.
hamilyon2 6y ago
I always wondered what would HN say in this case. Clearly, steam is rolling its own crypto here, against established practice.

523 points by zertrin 6y ago

If you are wondering why they do this, the answer is not because they don’t trust TLS. It is (likely) because they use geographically distributed terminating load balancers, perhaps owned by someone else or run in someone else’s POP, and are trying to prevent passive collection of passwords.

gruez 6y ago
I guses that works, but it only really prevents surreptitious password collection. If you're in a position to do active attacks (eg. MITM), you can just substitute their public key with your own.
- lights0123 6y ago
  For sure, but it's at least possible for them to set up a honeypot to detect that.
  - gruez 6y ago
    Yeah that prevents mass surveillance but doesn't prevent targeted surveillance (think steam account with valuable skins).
    - noobquestion81 6y ago
      The stakes are “we lost all the user passwords”. This is a problem that can occur if e.g. the POP is logging too many things. Preventing passive collection at POPs also prevents all sorts of footguns like these that can lead to a breach, it is smart security sense IMO.
- est31 6y ago
  You might be "only" admin of such a MITM box and can maybe only see/search the decrypted contents but not alter them.
nijave 6y ago
This would also cover intercepting proxies like many corporate networks have and potentially protect against less technical malware that installs MITM proxies on the local computer and root CAs to intercept local traffic (not sure if this is still a common type of malware on Windows computers but I've seen it before)
mminer237 6y ago
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.
- jaywalk 6y ago
  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.
  - mlyle 6y ago
    Those geographically distributed SSL-terminating load balancers could still conduct such an attack, SSL or not.
    - jaywalk 6y ago
      Yep. If any sort of MITM attack was their motivation for this, they didn't really think it through.
      - crdrost 6y ago
        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.
yuliyp 6y ago
It also potentially protects the passwords from their web servers if they implement it like that. They can pass the encrypted password to a separate service that has the private key and decides to give you a session or not.
deleted 6y ago
[deleted]

RexM 6y ago

World of Warcraft also uses SRP for logging in via the game client. Or at least they did when it was originally released, I don't know if that's still the case.

Cthulhu_ 6y ago

I've heard about the security of a mobile banking app about eight or so years ago, when mobile banking was still very much a new thing and trust was a big issue. They too opted to write a second encryption layer on top of TLS / SSL, fearing MITM attacks. That was also when iOS didn't support SSL pinning yet. It seemed to work for them, security researchers went to town on it and while they quickly discovered there was a second encryption layer below SSL, they were unable to determine what it was and how to crack it. IIRC their encryption was never broken, and thanks to that track record, they slowly increased daily spend limits over the mobile app. Long term, because they were very forward-thinking and they had competent native app developers (as opposed to the competition who struggled for years with mobile web / crossplatform tech), they increased their market share by a lot, now being the largest bank in NL; can't find historical data, but they went from 37% in 2016 to 40% in 2018.

lol768 6y ago
There was a UK retail bank that tried a strategy like this. I maintained (and still do maintain) it was security through obscurity and a waste of engineering effort that should've been spent on actually hardening the banking API server and migrating it to a modern stack. I thought it inevitable and indeed - it got cracked twice anyway (despite the use of Arxan, extensive anti-debugging functionality and rewriting the crypto on at least one occasion).
- sjtgraham 6y ago
  Barclays? Was cracked both times by me :) Disagree that hardening the API server is any better. This is the approach common in the US market, and my team has broken everything available there too. Also disagree with insinuations that these banks don't have good, modern stacks. Barclays in particular is great. Way better than any challenger bank. Lloyds also took a similar approach to Barclays but they did a better job than Barclays did (although Barclays did a great job themselves too) and so we never got around to finishing it before we pivoted to the US market. As far as I know it's still unbroken, although I'm pretty sure my colleagues could easily break it today. We've since developed far more sophisticated reversing techniques.

netsharc 6y ago

Yahoo! Mail also does (maybe "did", I looked at it a decade ago) something similar. When the user opens the login page, s/he gets a random string in one of the hidden form fields, IIRC it hashes the user-entered password, and then adds the random string and hashes it again, and sends this result to the backend. On the backend, it knows the random string it sent to the user, and it has the hashed password in its DB, so it can do the same algorithm and compare the results.

k1t 6y ago
The danger with that approach is that the hashed password has become the password. If the hashes are leaked, they can be used to login.
- lostmsu 6y ago
  That only works if the string is the same each time. But it won't, if it changes like TOTP code.
  - jarkhen 6y ago
    If the string changes each time, how could they possibly have the matching hashed password stored in the database?
    - fgonzag 6y ago
      They have the users password hash stored in their db so they can replicate the process server side: login_token = hash(pwd_hash + nonce) its nothing too wild, especially considering the age of yahoo mail.
      - jarkhen 6y ago
        Ah, right, I misread the original description of what they were doing. As is, then, it really is just making the hashed password the new password. If I can get the hashed password out of the DB, I can load the login page and simply skip the initial hashing step that's done on the frontend. I now have access to the account without ever knowing the original password.

thoughtsunifi12 6y ago

delete thoughtsunufic account

simongr3dal 6y ago

I’m just annoyed that Steam still doesn’t support standard TOTP two factor but uses either an email code or their app.

kuroguro 6y ago
If you root your phone you can get the secret out and use it with regular TOTP software that implements that variant (I forgot the name - I just know Bitwarden supports it).
- pzmarzly 6y ago
  There are some desktop implementations of Steam TOTP client, so you don't even need a rooted phone, as long as you trust some random open source code. https://github.com/KeeTrayTOTP/KeeTrayTOTP#documentation https://github.com/KeeTrayTOTP/KeeTrayTOTP#documentation
  - kuroguro 6y ago
    > In the case of Steam Mobile Authenticator the new output format was reverse engineered by various developers Oh, so it was a custom one! Was convinced that it was a less used standard algo.
fuzzy2 6y ago
Not just that, I just noticed that the Steam app does not support iPhone backups. Blizzard app does, as does the Verisign VIP Access app. Pretty lame. The restore SMS didn’t arrive on time either that evening, fun!

aasasd 6y ago

I keep being somewhat baffled by Steam's login process every time I'm forced to go through it. Apparently Steam is such a cesspool of (pre)pubescent teenagers, with rampant account hacking and theft of funds, swag or whatever, that they feel the need to fortify the process if only to make it more inconvenient for the hackers. - “Remember the password” barely ever works, even on desktop. Since I don't quite log in every day due to being too old for that, I have to redo the process every time—on a machine that I bought with my own money just for myself and intend to protect with both technical means and physical force. - Somehow copy-pasting passwords from KeepassX/XC doesn't work on Mac, with the shortcut. Not sure if this is a misfeature of Steam, but I have to paste the password to an editor first and then copy out of there into Steam. (Seems though that ‘paste’ in the context menu does work—this might've changed since I first noticed the issue.) - And of course, the weird variation on 2fa, via email, instead of the good regular TOTP. As is tradition by now, I'm also given the choice of installing yet another app on the phone, which somehow doesn't quite seem to serve my interest.

Nullabillity 6y ago
FWIW, the app uses a variant of TOTP. Some TOTP apps (including one for Yubikeys[0]) support generating them if asked to. [0]: https://github.com/Yubico/yubioath-desktop/issues/72 https://github.com/Yubico/yubioath-desktop/issues/72
blackearl 6y ago
How often are you logging into Steam? The app stays logged in for me pretty much forever
- dfabulich 6y ago
  I have the same issue. On Mac, I log in to Steam about once a week (sometimes longer than that). I have to login with my password and get a Steam code almost every time.
  - dkersten 6y ago
    Huh strange. I’ve used steam on windows, Mac and Linux over the years and with different frequencies of use and still only ever have to manually log in once every few months.

bArray 6y ago

One reason not to trust TLS is that it's one system that you want to be secure for all your users - indefinitely. If in the future there was some method to crack the TLS or the appropriate keys/certs were leaked, any recorded traffic could be retroactively cracked. Remember also it wasn't so long ago we were talking about things such as POODLE attacks. For all we know, some bad implementation of TLS 1.3 could default to some crappy easy to crack algorithm. I believe there was a paper (can't find it now) that speculated about the cost to crack a specific TLS setup to be about $10 million USD in processing, going back some years. (I think it was in reference to some half of VPN traffic at the time using the same keys.) If Moore's law still applies in any sense, that cost likely halves every two years and people only really change their passwords if they have to. Another reason is that it reduces risk server side if you are never handling user passwords - at worst an attacker gets a temporary hash that's valid for a short time, specific to that server. Maybe they can do some harm during that time, but you can ultimately revoke that key and undo the changes to the user's accounts.

sonotmyname 6y ago
> If in the future there was some method to crack the TLS or the appropriate keys/certs were leaked, any recorded traffic could be retroactively cracked. This is incomplete. TLS does allow for ciphers that enable Perfect Forward Secrecy (PFS) to prevent this. Those ciphers are not the most commonly used ones, but to describe TLS the way you do implies it's a flaw in TLS.
- johncolanduoni 6y ago
  I thought ECDHE or X25519 suites were pretty common these days; I appear to get the latter when connecting to Cloudflare hosts for example.
- bArray 6y ago
  > This is incomplete. TLS does allow for ciphers that enable > Perfect Forward Secrecy (PFS) to prevent this. Sure, it was simplified. I can't remember exactly what the support was like for PFS? And given it probably requires additional exchange for DH, I imagine it would be disabled due to resources reasons.

mschuster91 6y ago

> That begs the question why. Why bother creating such a weirdly intricate system on top of something that works just fine on its own? I have my own theory, but keep in mind it’s just that. To avoid admins (or hackers) in enterprise "SSL breaker" boxes from exfiltrating passwords.

mminer237 6y ago
How many enterprise admins are trying to get employees' Steam passwords? I think the "it used to support logging in without SSL" theory is more likely.
- meibo 6y ago
  I wouldn't call it an impossibility, Steam accounts often carry a real, huge amount of value to their owners, going into the thousands of dollars of either games or trade items. Even if it wasn't the main reason, it probably played a role. Some small time admins in education facilities would probably have an easy time with this stuff and wouldn't get caught doing it.

txr 6y ago

This exact procedure is used for the pidgin plugin: https://github.com/EionRobb/pidgin-opensteamworks https://github.com/EionRobb/pidgin-opensteamworks

madisp 6y ago

The 3600 second + a bit (~1s) is a common thing that happens if your periodic scheduling work is one-shot and repeating is achieved through scheduling the task again after completion. E.g. consider the following code (in Kotlin, but hopefully still readable): fun rotateKeys() { publishNewKey(key = generateKey(), timestamp = now()) schedule(::rotateKeys, 1, TimeUnit.HOUR) } if `generateKey` and `publishNewKey` take around ~1s then you'll observe exactly this behaviour - the timestamps will start drifting from some original value.

mlyle 6y ago
Thank you-- I came here to post exactly this. Very easy to get something skewing by a second if, say, the key generation takes a second.
- xtacy 6y ago
  Or, you could (re)schedule first and then generate the key? Assuming that key generation doesn't take an hour, of course. :)
  - madisp 6y ago
    Ideally you'd use something modern that invokes your function every hour (cron? :P) so that the rescheduling is detached from the function. I think if generation takes X hours of raw CPU computation where `X >= 1` then as long as you've got C cores and `C > X` you should be OK?
    - hatsuseno 6y ago
      Out of curiosity, why is having the process scheduled tightly with (something akin to) cron ideal to you? atd is, to me, a perfectly reasonable alternative. I guess it depends on the environment a developer finds themselves in when implementing the feature. It might just be easier to setup the next scheduled job than implementing cron-like features in the system that does the executing of scheduled junk.
  - 6y ago

qorrect 6y ago

> The internet was a different place though in the early 2010s Oh how far we've come. /s

Taylor_OD 6y ago
Uber didnt exist in early 2010.
- qorrect 6y ago
  Pirate Taxi's have existed for decades, the mobile app for them did not yet exist.

syoc 6y ago

There was some discussion on /r/netsec where this was published as well. https://www.reddit.com/r/netsec/comments/ksn6rc/steams_login_method_is_kinda_interesting_rsa/ https://www.reddit.com/r/netsec/comments/ksn6rc/steams_login...

BlueTemplar 6y ago

I wonder what did they use between 2003 and 2012 ?

superkuh 6y ago

It's not listed anywhere on his site but by random guessing of URLs I found his RSS feed: https://owlspace.xyz/index.xml https://owlspace.xyz/index.xml

MayeulC 6y ago

If you want fancy password-based authentication without transmitting it, have a look at PAKE (and OPAQUE): https://news.ycombinator.com/item?id=18259393 https://news.ycombinator.com/item?id=18259393

jordache 6y ago

This is clearly a violation of security good practice tenet of not implementing novel patterns.

throwaway09223 6y ago

Not transmitting the password is good practice for the same reason it's good practice to not store passwords cleartext: systems can be compromised. I trust we all agree that storing cleartext passwords in a database and doing a simple string compare is a problem so I won't rehash that bit. If a login server is compromised then attackers can harvest cleartext passwords. It's the same class of problem with a reduced attack surface. There is no good reason to transmit a persistent authentication secret as part of authentication. Just don't do it.

yuliyp 6y ago

Regarding the rotation timestamps: My guess is that the rotation is implemented as a "generate a new key when needed" rather than a cron: When someone asks for a key to issue to a user trying to log in, try to fetch a cached one. If one is there and it's < 1 hour old, return it. Otherwise generate a new one and record its timestamp.

T3RMINATED 6y ago

zis is a blog by some german nerd.

nirushiv 6y ago

How does this work implementation wise? One private key per application? Per user? Or refreshed on a per-login basis on the first POST?

sroussey 6y ago

Repeat from a couple days ago: https://news.ycombinator.com/item?id=25690995 https://news.ycombinator.com/item?id=25690995

hutattedonmyarm 6y ago
I posted even earlier: https://news.ycombinator.com/item?id=25684254 https://news.ycombinator.com/item?id=25684254 But I’m happy to see it got some attention after all!

sroussey 6y ago

I mentioned this on Twitter[1], the reason to encrypt before sending over SSL is not about double encryption, it’s about how a large backend system is designed. Often, you have load balancers that are SSL endpoints, so the data is decrypted at that point. You can start to see the problem already. What if there is a different bug, and so a dev starts logging requests somewhere down the line? You accidentally start logging cleartext passwords. Oops. Facebook was fined for this not that long ago. But if the password is encrypted, then it’s not really an issue, and the black box blob can be forwarded to a login microservice. There, the team decrypting will be on higher alert. So depending on the structure of various teams, you now have fewer teams that need that kind of security oversight and can move faster. Smaller blast radius of something goes wrong. [1] https://twitter.com/sroussey/status/1347688753221931010?s=21 https://twitter.com/sroussey/status/1347688753221931010?s=21

xwdv 6y ago
So what you’re saying is if you know what you’re doing and you don’t log any clear text passwords it’s fine to not double encrypt?
- colechristensen 6y ago
  If you are immune from mistakes, sure. Making decisions as if you are immune to mistakes is a good way to ensure you prove yourself wrong in the worst way. Making decisions to prevent things which should be impossible is how you build reliability.
  - remexre 6y ago
    And, adding assertions / very loud logs is a good way to be sure your assumptions hold: e.g. causing your tests to fail if the test user's password (or other privileged info, etc) appears in any logs is a fairly good extra safety layer.
    - sroussey 6y ago
      That’s a great test idea I have not used myself, thanks! I’m also working on forks of logging systems to make them smart about what they log in the first place, but not quite like the Palantir does it.

cafed00d 6y ago

It's stuff like this that makes me wish for a _version_ of Windows that is completely built & operated by Valve. Or atleast, I wish Microsoft could implement such features for their login interface. I love gaming on Windows & PC and would love to have the PC have a "Big Picture mode" friendly UI, _throughout_ the OS. Some gimmicks I have had to resort to are to set up my PC Sign-In to be _without_ a password and on a _local account_ on my Win10 PC, along with having Steam start in BigPicture on startup. This way I can switch on my PC and have my controller connect to start gaming just like a console; but way better graphics of course :) It's these tiny affordances that collectively add up to great User Experience features.

mxscho 6y ago

Steam and especially CS:GO has a problem with phishing sites (with fake Steam OpenID pages) where attackers (after getting access to the Steam accounts) can automatically create permanent access to accounts by generating API keys to control those phished accounts. This is used e.g. to swap trade offers in realtime, i.e., a trade offer with the actual account is replaced by a trade offer with a bot with a similar looking profile (all set up automatically). All of this is done in the timeframe between the user setting up the trade offer and the actual 2FA mobile confirmation of this trade. People are being phished like this for years and Valve fails to take the responsibility to implement a simple anti automation measure at the part of API key generation (e.g. email confirmation or captcha). The monetary damage done to users is probably in the high thousands, if not millions, at this point in time.

bricss 6y ago

It seems to me that whoever wrote this article has no idea what an MITM attack means.

rvr_ 6y ago

Steam was always a high target for hackers and a low target for law enforcement (who cares about your stolen games?). It makes a lot of sense for them to implement every security method conceivable.

simias 6y ago

Seems awfully complicated, slow and error-prone to use full blown RSA for this. Why not send a challenge token and hashing salt and ask the user to reply with the (effectively one type password) crypto_hash(crypto_hash(salt, password) + token)? On the backend they already have crypto_hash(salt, password), they know the token they sent so they can build the same hash and see if it matches. This way the backend actually never has access to the non-hashed password. The only inconvenient I can see is that you can't transparently rehash on login on the backend if you decide to migrate to a different, potentially stronger hash algorithm later. But then again if the worry is that passwords could leak in the backend, using hashes makes it effectively impossible by construction. I guess nobody gets fired for using RSA. But at the same time doing "serious" crypto in JS always feels icky to me.

josalhor 6y ago
I have wondered many times why we still send the password over the wire (even if in SSL). It should be hashed with a salt every time before being sent! A lot of people reuse their passwords, the user shouldn't trust the website to hash it.
- dfox 6y ago
  Because calculating the salted hash on the client side will just substitute the hash for password and render the whole hashing useless. Also it would require additional roundtrip to server in order to get the stored salt. Then there is the UX problem where mechanism like that would have to be implemented on the browser level (and in fact it is as Authorization: digest is mostly what you are proposing) which according to some leads to “ugly and confusing” UI.
  - josalhor 6y ago
    > Because calculating the salted hash on the client side will just substitute the hash for password and render the whole hashing useless. I don't understand what you mean. Just in case I didn't make myself clear, I don't mean substituting the hashing on the server, I mean adding it on the client. > Also it would require additional roundtrip to server in order to get the stored salt. It could be salted with some constant/domain name. > Then there is the UX problem where mechanism like that would have to be implemented on the browser level What I am saying could perfectly be done with javascript, although I don't see why browsers could not integrate it too. > which according to some leads to “ugly and confusing” UI. I am completely lost, I am not sure if you understood me but I don't understand what you mean. Can you explain yourself further or provide a resource that explains this UX problem you're talking about?

RupertWiser 6y ago

I kept reading waiting for the author to address man in the middle attacks but no mention. This adds no additional security. You can easily provide your own keys or JavaScript and completely bypass this. Like others have suggested, I get the impression this system is assuming TLS will work and perhaps isn’t trusting the server the password ends up on.

deepsun 6y ago
There is additional security. It's much harder to modify traffic, not just observe it.

deepsun 6y ago

tl;dr: User client requests a public key from Steam's servers (rotated each hour), and sends passwords encrypted with it.

warpech 6y ago

From the OP > the login page also sources jQuery version 1.8.3 which was released in November 2012 Wow, that's a prime example of "if it works, don't change it"

apatheticonion 6y ago

How hard it is to move to using OIDC with commonly implemented features such as SSO, anomaly detection, passwordless login, app based MFA, etc? It's good enough for major financial institutions and available as a service using any number of providers (like Okta, AWS Cognito, Auth0). I love Valve and Steam but their game launcher client (Steam) lives in the stone age when it comes to use of technologies. That said, it's far better than the competition so I am still happy, but it is still annoying.

spondyl 6y ago

On a side note, I'd like to say I'm a big fan of this blog theme the author has going. It has a kind of homey feel thanks to the owl and the little + symbols in the background wallpaper

g7r 6y ago

This strange solution looks like a legacy of times when Steam used HTTP instead of HTTPS. Maybe they just didn't bother to update working code after migration to HTTPS?

bullen 6y ago

I use single serving server salt and SHA256 hashing for my logins: http://talk.binarytask.com http://talk.binarytask.com

jzer0cool 6y ago

I always had some concerns with desktop apps / mobile apps. Unlike browsers which has a lock symbol how can desktop apps inform whether communication is over tls for example? There is also the challenge that it 'was' tls at one point when you first inspected but could later changed to some non secure transmission without being informed of such change. What might be some solutions to this? I have yet to see anything that is standardized for this purpose. Other than, loosely here, 2fa token for purpose for login only, but is still without knowing whether transmission to endpoint was over secure channels.

gitgud 6y ago

Not sure if anyone noticed, but according to the "login.js" snippet, Steam removes all non-standard ascii characters from the password, before encrypting it... Doesn't that essentially reduce the password's strength? Especially if there's a lot of non-ascii characters in it....

roelschroeven 6y ago
I would think so, yes. Maybe they are trying to prevent problems with users logging in from computers using different code pages? Is that still a problem?

asdfsfkwqe 6y ago

In corporate networks, you often need to install a root CA. Thus HTTPS essentially became HTTP for network admins.

ezconnect 6y ago

This is done by bank login page during the 2000s and still being done by my bank and other bank login page.

hamilyon2 6y ago

I always wondered what would HN say in this case. Clearly, steam is rolling its own crypto here, against established practice.