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.
However a better approach to this problem is to not rely on shared secrets. Use public key signature tech to stop worrying about mistakenly logging a secret. If you never had it, you can't lose it.
If you were to log literally every byte of the plaintext traffic when I sign into GitHub (e.g. maybe you're a GitHub ops person), you don't get the ability to sign into GitHub as me. There's a WebAuthn signature step, my signature is authentic, and you can even verify that from your log if you want, but you'd need to make a new signature to sign in, and you can't do that because the key needed to make my signature never left my hands.
Even better, GitHub defuses their liability because as well as a (presumably hashed) password that could be broken by a hypothetical attacker they've got a public key for me, and learning that public key doesn't help the attacker do anything, at their site or anywhere else. Even - unlike with the SSH public keys GitHub holds - to identify people, since WebAuthn public keys are deliberately uncorrelated you can't match my GitHub key against a Facebook key for example.
Yeah, I do hashing client side as well as server side. It's not ideal - what would be ideal is zero knowledge proofs for such a thing. But it's basically:
hash(static-pepper, username, password) * 250k
That + tagging the password with "password++" or something means that you're a lot safer against the major issue of leaking a password before it's stored, for example the mistake that definitely happens everywhere of "let me just add request logging, whoops there's everyone's plaintext passwords". You can always search your logs for the 'password++' tag and alert if you find it, and if that does happen at least you know an attacker isn't going to have an easy time extracting a plaintext password - it buys you time.
And if an attacker gets SQLi or whatever and dumps the passwords they're that much harder to crack - you've added hundreds of thousands of iterations of key stretching, and it's totally distributed to clients so you don't even have to worry about it blowing up your db/ auth service CPU.
And it's trivial to implement, which is the really important part. ZKP is a lot more work, but what I described is like 5 extra minutes and pretty trivial.
Though this is obviously better from a wire-interception PoV, it means that you can't enforce any password policies, or maintain a list of leaked/bad passwords (e.g HIBP)
You can enforce password policy client side. A technical user can go way out of their way to bypass it, but honestly, at that point who cares? If you really want to you can send up some metadata or something I guess.
Another option is to send the password at user creation time, but then to rely on a hash at login time. Now there's leak potential, but it's you just have to audit for leaks in one part of the codebase.
There's a lotta stuff you can do to improve upon the very quick version I'd mentioned.
It's definitely not equivalent. The plaintext isn't (as easily) recoverable, which means that if the user used the same plaintext password for another service it's (somewhat more) protected.
Pass The Hash is also protocol specific - if you try to replay a hash to your average HTTP service it won't go "oh, it's already hashed, thanks" it'll just hash it again and you'll fail to authenticate.
> Then just add a time sensitive seed to it? I don't think it is equivalent to leaking plaintext. It can't be used to guess passwords on other websites.
You're reinventing password hashing and salting. Further, there's no guarantee that the has cannot be used to guess passwords on other sites. For what benefit, exactly? Your hash is now the password, and basically as dangerous as it was in a more conventional arrangement.
Pass-the-hash is a real kind of vulnerability that has been used to exploit real systems. We might be better off sticking with design approaches that don't have this problem instead of trying to fix out way out of the problem.
> If your SSL layer is compromised, you can't trust the client-side encryption. The attacker can send arbitrary javascript.
Are you sure this is what it's guarding against? A sophisticated application architecture might involve a load balancer decrypting and doing the initial routing, several sets of data handoffs, and then the application that needs it handling the password. Any one of them could mishandle or leak the password, but only the one at the end actually needs it in the clear.
How exactly is asking for my password to be hashed "reinventing password hashing and salting"? Seems like the opposite, no?
If your password is properly salted, it can't be used to guess passwords on other sites, that's the whole point of salt and hash.
The fact that RSA is being used means that your plain-text password is going to appear on their servers. Maybe it won't get cracked in the SSL layer, but it is still there.
> Are you sure this is what it's guarding against? A sophisticated application architecture might involve a load balancer decrypting and doing the initial routing, several sets of data handoffs, and then the application that needs it handling the password. Any one of them could mishandle or leak the password, but only the one at the end actually needs it in the clear.
Do you realize that if an adversary even only has read access to the SSL layer, they can just copy the cookie and steal the account that way?
You'd actually end up hashing it twice. Once using the salt to go from plaintext to what the sever has stored and then again using the challenge.
It has problems though. The strength of your password hashing would be limited by what the weakest client could do, rather than what the server could do. Asymmetric encryption ends up being simpler.
At some point we must simply “know what we are doing” and do something. Software would be a tedious affair if you have to approach everything from the perspective that maybe you don’t really know what you’re doing and need to implement some way to verify.
What are unit tests, linters, SAST tools, and more all for? Naively, it seems to me that we swim in a great sea of tools to verify that we do, in fact, know what we're doing.
The other comment mentions tests, but I'd like to that to that. The reason why it's impossible for anyone, even the single greatest programmer on the planet, to not create bugs, is due to the high complexity of the software we write. It's not so much that you'll make a mistake when creating a new program. It's that over time, as you make more and more changes, it's impossible to actually trace out the exponential complexity that arises from your changes.
The purpose of unit tests is to catch these, and yes as you mention lower down even those aren't 100% infallible but they greatly help. That's why even with some of the greatest programmers and extensive testing, we still constantly see major bugs from every single top tech company. I don't think there exists a single completely bug-free software of non-negligible size out there.
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.
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.
this approach tends to be a self-own. Bug bounty and responsible disclosure folks don’t usually have expertise in it, so you’re just making the real attack surface less visible until someone with the expertise comes a long and owns you deeper than you could have imagined. This, ironically was also the case for steam: https://steamdb.info/blog/breaking-steam-client-cryptography... (I helped make this bug)
There is a misconception that the responsible disclosure system reflects real security threats, but it unfortunately doesn’t. The areas of expertise in the real world are different, and sticking a bunch of crypto in like that tends to be a case of making your eventual problems more complex, bigger, and harder to find.
I humbly disagree - there are times when application-level crypto makes sense. E2EE in particular relies on application-level crypto, and any password manager or "secret server" that relies only on TLS is highly suspect, in my opinion.
I attended a talk at QCon SF 2019 where the speaker advocated use of application-level encryption (even in web apps) by default as a form of defense-in-depth. I was skeptical, especially since client code itself has to be delivered using TLS only (and thus a successful TLS attack renders further defenses worthless).
But it does seem that application-level crypto allows a lot of networked devices (besides the application servers themselves) to be rendered zero-knowledge concerning most application and user data. This allows us to trust those devices less.
I never made the argument that no application should ever encrypt anything at the application level. Password managers are very niche uses.
"secret servers" or key-management systems are just fine using TLS imo. I helped draw up the design for what is now the aws secrets manager. At the point you're reasoning about TLS being broken you might as well be focusing on detection, monitoring and key rotation because the whole internet is coming down with you.
> I attended a talk at QCon SF 2019 where the speaker advocated use of application-level encryption (even in web apps) by default as a form of defense-in-depth. I was skeptical, especially since client code itself has to be delivered using TLS only (and thus a successful TLS attack renders further defenses worthless).
defense-in-depth is a weasel word. security isnt a bunch of layers that can be reinforced as such; often things that are referred to as 'defense-in-depth' cover specific characteristics of one protocol over another.
For example, in password managers as you mention you end up with application level encryption. But this is because TLS doesn't provide the guarantees they want of server blindness, and some resistance to bad TLS certs installed at the OS level (a dubious security boundary, but regardless...).
> But it does seem that application-level crypto allows a lot of networked devices (besides the application servers themselves) to be rendered zero-knowledge concerning most application and user data. This allows us to trust those devices less.
This may well be true in niche cases. In reality, there's not a lot of businesses out there who will overengineer their systems to know less about their users. zero-knowledge applications are unbelievably subtle to make really work, and it's very easy to fool even experts in adjacent security fields that an application is zero-knowledge in some respect when it isn't.
I'm digressing. Application-level encryption in 2021 is very rarely what's wanted, and the existence of niche security cases in entirely security-focussed products doesn't discount that.
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).
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.
> 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.
By "hardening the API server" I mean fixing actual security vulnerabilities and improving the security posture of the API gateway, not going for further obfuscation layers or attempting to prevent third-party clients. Those are a waste of time. My position is that there's no point trying to prevent the user's access to his own data - but there is a point in enforcing e.g. access controls so customers can't access data for accounts they don't own or spend money they don't have.
When you talk about "breaking" banks in the US space, are you referring to gaining access to the API and reversing it (which has always been Teller's MO, no?) - or finding vulnerabilities with the API endpoints with actual financial implications for the institution?
> Also disagree with insinuations that these banks don't have good, modern stacks
I'm aware of your thoughts on this, though I respectfully disagree with the "modern" characterisation you have applied to legacy banks based on the sorts of tech I've seen and how it e.g. coped when faced with such exotic things as non-ASCII characters.
Monzo have at least never wasted time on obfuscating the fuck out of their API comms, nor forcibly preventing me from accessing my transactions on my rooted device or running their app under a debugger.
With respect I think you're speaking outside the bounds of your knowledge of these systems.
> By "hardening the API server" I mean fixing actual security vulnerabilities…
That is just table stakes. Have you ever found any vulns in bank API gateways? We tested authorization boundaries with our own accounts, we didn't ever find a bug like that. I found a total of two bugs quite low impact. One was unsafe object deserialization that could potentially lead to RCE, we obviously didn't try this. The payload was signed so it most likely would have been difficult to exploit provided the signature was verified before deserializing the object. The other one was an authentication bypass, which potentially could have given you read only access to the user's accounts. You could then call up customer services and use recent transactions on the account as a knowledge based 2nd factor to be given a code to upgrade the read-only enrollment to write access. This would require some knowledge about the customer (account number, telephone number, etc) and sloppy CS, so would probably say that was also low risk. We reported both to the respective bank via internal contacts.
> When you talk about "breaking" banks in the US space…
Everything this thread refers to countermeasures banks employ to keep third parties from leveraging their private mobile API gateways. When I talk about breaking things I'm talking about breaking these countermeasures.
> I'm aware of your thoughts on this, though I respectfully disagree with the "modern" characterisation…
The content encoding of the underlying persistence layer is a tiny part. Their technology is broadly speaking very good. I am probably the world expert on the state of these systems because I have very deep knowledge of a large number of them, whereas even bank employees would only about their employer's systems.
> Monzo have at least never wasted time on obfuscating the fuck out of their API comms…
Monzo did other stuff to effect the same result, i.e. they only allow one device to be logged in at a time. So you couldn't use Monzo's app AND access your account via Teller at the same time.
I wouldn't use Monzo as an exemplar of technological capability. Barclays absolutely smokes them.
> With respect I think you're speaking outside the bounds of your knowledge of these systems.
I'm not going to argue with you on this; you're entitled to your opinion :)
> That is just table stakes. Have you ever found any vulns in bank API gateways?
Infosec consultancies find vulnerabilities in the API gateways of retail bank clients, yes. That's one of the things they are paid to do. And yes, I found issues myself in part of the open banking consent flow I was asked to test for a retail bank when I worked for such a consultancy. Such features don't get built without flaws.
The folks who are smart enough to reverse the mobile apps, any crypto used and write their own client get to play with these features in prod after they've been tested (either internally or via a contracted pen-test firm).
> Everything this thread refers to countermeasures banks employ to keep third parties from leveraging their private mobile API gateways. When I talk about breaking things I'm talking about breaking these countermeasures.
Then we seemingly agree these countermeasures are not effective - which is the point I attempted to express :)
> whereas even bank employees would only about their employer's systems
I have never been a bank employee so don't personally know, but presumably some of them move between orgs.
> Monzo did other stuff to effect the same result, i.e. they only allow one device to be logged in at a time. So you couldn't use Monzo's app AND access your account via Teller at the same time.
Only if you were trying to impersonate Monzo's iOS/Android OAuth clients instead of the expected AISP/PISP flows.
I remain convinced that rewrite was a purely anti-competitive move to stop/slow Teller and others. As someone that worked on a startup that required API access to transaction data, it was a huge pain in the ass having to write and rewrite screen-scrapers.
Security through obscurity isn’t an invalid technique if you also are doing security through cryptography too. One reduces your attack surface, the other reduces the number of attackers by increasing the required effort - both work. In part this is why many IoT devices also attempt to physically protect the underlying microchips, why HSMs destroy keys when enclosure tampering is evident, etc.
> Security through obscurity isn’t an invalid technique if you also are doing security through cryptography too
It becomes a distraction vs actually writing a secure set of endpoints in the first place.. Folks get a sense of security from it which is entirely false.
The funny thing is, before the current ING app, there was a super crappy app that used an MSN chat bot on the background to query your account balance.
But indeed as you describe, since 2012 or so, the ING app is formidable and built by amazing people.
Source: I work at ING, in IT, but in a completely different area.
Funny you should say that, I'm looking at my ios codebase from 2010 for an eastern-"ish" european bank that hired us to build their first banking app. They wanted a completely custom encryption layer in their app for all communication. I don't know if it was a case of not trusting the current tech standards, or a case of believing their engineers were better then everyone else. They were in charge of the SecurityCenter framework, we did everything else.
> "Het authenticatie protocol ziet er goed doordacht uit. Er wordt niet vertrouwd op SSL of TLS. In plaats daarvan gebruikt ING een extra encryptielaag waarvoor het wachtwoord wordt afgesproken via het SRP protocol. Ook genereert elk mobiel device een eigen profileId en een public/private sleutelpaar", merkt Van den Berg op.
In English:
> "SSL/TLS isn't trusted, instead, ING uses an extra encryption layer the password of which is negotiated using SRP. In addition, every mobile device generates an own profileId and a public/private keypair"
Don't know if op was indeed talking about ING, but their app was, for a time, very wrong on Android as they seemed to have rewritten it on a Cordova/Phonegap stack which subsequently tanked their rating on the play store. Looks like they have released a new native version since then - at least on the french store.
For a bank, increasing national market share by nearly 10% in just a few years is a pretty incredible feat. People don't generally shop around banks for checking/savings accounts, and the switching cost is very high and a pretty manual process (at least in the US, may be less onerous in NL).
Switching-cost in US can actually be negative - many banks will pay you hundreds to set up an account and get direct deposits to it for a small (~3mo) period. Payroll software is generally happy to split deposits, so this isn't a real barrier to entry.
The real barrier is who wants to bother switching banks? It's new UI to learn, new passwords, new apps, new cards, new exposure to security flaws, etc etc etc. I don't think that's any different in US vs EU.
Yes, bait-money exists in europe too. Because of which some people are constantly moving around their accounts, or just have multiple accounts for different purposes.
Until 2018(?) this was really simple, because there where good APIs for online-banking available. All you did was adding a new account to your software and call it a day. But new security-rules for EU kinda killed them off, and banks are putting up more barriers against bank-hoppers. So at the moment it's a bit in transition.
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.
Hmm, what I mean is, I open up Steam on my Linux system. Usually it remembered my login but sometimes I need to login again. If I then type my password, it says: "type the code we emailed to continue".
So if I wouldn't have access to that email account, I couldn't login and lose the Steam account, even when knowing the password.
Although, some of the methods from the link would still work, so that's solved, I guess.
Except that even if you use Steam Mobile you can't turn off email-based "self-service account recovery" in Steam. Your email account is always going to be the final key to control of your account.
Which is why my email accounts have warned me that every time a botnet cracks my Steam account password there are attempts to open what they think is my email account with the password they just cracked. My Steam account password these days is cracked scarily often, and I'm afraid my Steam account is now one of my weakest links in my online security footprint. I'm not dumb enough to use the same password for my email addresses as my Steam account, but the fact that Steam seems to be allowing password spray fast enough that machines keep cracking 50+ character passwords in days is alarming.
(ETA: Note the reason I mention 50+ is that I specifically vary the length randomly; when I don't the cracks drop to hours apart.)
However, near as I can figure, it offers no way to provision a second device with the same seed (or store the seed).
It's one of two sites that I use TFA for that I don't have a backup for, which is mildly annoying. I do have recovery codes, and will all too happily fall back on SMS.
I'm not sure what you mean by auto-login not working. I've had my Steam account for 11 years and I can remember a time where that was the case, but it works so reliably nowadays I didn't even remember it was an issue until reading your comment.
I'm 90% sure it's a account-based bug. My account has had this issue for ~6 years now (I've used steam for 15 years). It happens on any browser or device. No cookie clearing, doesn't happen to any other account, etc. Every time I bring it up, the majority of people say they don't have an issue, while a small handful of others chime in about experiencing it too.
It has to be a bug, or maybe a security feature for accounts of a certain size?
I think they restrict the 2FA methods since they want tighter control over them. For example, if you use their Steam app for 2FA and you need to move it to a new phone your account gets put into a restricted mode and you cannot use the Community Market for 15 days. This restriction also gets applied to any item you touch, so if you trade an item to someone else, the store restriction moves with the item.
They also strong-arm you into using the app. If you log into a new device (or Steam thinks it's a new device since you cleared cookies) and you don't use their app for 2FA, then the device will not be able to trade or use the market for 7 days. They only waive this restriction if you use their app for 2FA and it has been active for at least 7 days.
It's a bit frustrating since the Community Market/Trading is likely only used by a minority of users, but seemingly a ton of login limitations are imposed because of it.
> It's a bit frustrating since the Community Market/Trading is likely only used by a minority of users, but seemingly a ton of login limitations are imposed because of it.
It's probably because it moves a significant amount of money, between trading cards, CSGO knives, TF2 hats, etc. Of course, nothing comparable to banking systems and general-purpose marketplaces, but I personally think those protections only add to the product.
> Of course, nothing comparable to banking systems and general-purpose marketplaces
Rumor is, some MMO games have markets exceeding GDPs of plenty of first-world countries, and ingame items are used by gangs to move funds across borders. Both Cory Doctorow and Neil Stephenson wrote books featuring this phenomenon, and I'm pretty sure they both usually take their ideas from reality.
Since Steam is a Big Guy, and its market is dedicated to this very activity and sits on top of many games at once, I'd guess it to have a sizeable slice.
Doctorow's book is “For The Win” (if I'm not mistaken—really need to get into the habit of writing some notes about the books I read, especially when marathoning through an author's bibliography).
Stephenson's book is “Reamde”, which is a weird, even for him, mix of realistic-sci-fi-about-computers with an adventure thriller.
I think I also found some articles about actual size of virtual economies and the use of them by crime. But those likely went into the Pile To Read, which is a rather sad fate in my case and the hope is thin.
I don't use the Steam 2FA app and when I sell Steam trading card, there's a banner saying 'you haven't used our 2FA, market listing will be held for 7 days'. But then usually the cards I list are sold the same day, I don't really understand why; perhaps because (on the Steam client), I rarely have to log in?
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.
Does the Mac version of Steam install through the Mac App store (or is it offered there), and does that store also have the webview restrictions? If that's the case, I'm wondering if that's triggering them to use web login methods, and while I haven't logged into steam on the desktop again since I installed it on this new one ~6 months ago, I have to log into the website and get a code almost every time I want to do something there, so I wonder if the Mac version of Steam is somehow under the web based login restrictions.
LOL, that's true. I wasn't even thinking of what Steam does, and was just considering it's authentication mechanism. Doubly silly of me, since I'm definitely interested and following to some degree the Epic lawsuit.
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.
I stopped using Steam because it was too annoying. Not sure what all they get up to for their anticheat crap, but something I do with my network/machine apparently sets them off.
Fighting with bullshit like this is not what I'm looking for when I want a game, so screw it, if a game needs Steam, I don't need the game.
It's not an issue with the app, it's in the browser only. I like using the browser for browsing since tab support is better, bookmarking and also extensions such as Steam Enhanced.
It's a weird variant of TOTP, but you have to be rooted or modify the app in order to extract the secret to use with other apps. Years ago I wrote a script to do it, but I'm not sure if it still works -- it's not really worth doing imo
The issue is that the app uses a custom protocol to confirm Steam community transactions (Steam inventory trades, etc). So if you use an authenticator like AndOTP, you lose the ability to confirm those.
I reverted to e-mail. I only have free software on my phone, and don't regret that choice.
> “Remember the password” barely ever works, even on desktop.
It happens to me only when I keep switching machines (sometimes I play on Linux, sometimes on Windows) => I guess that it's some kind of security check.
If I stick all the time to a single machine then I basically never have to re-login (if I don't stop playing for something like 1 month or longer).
I lost my password, access to my email address and all information that could have been used to identify me like my paypal account. This was somewhere around 2017. It took 2 emails to get them to transfer my account to my new email address and reset my password.
Here's my experience with recovering a Steam account. Some time before I lost access to my Steam account, I bought Portal 2 for the PS3 which included an activation code to get the PC version on steam for free. When I asked Steam support to help me regain access, they asked me to write a specific thing on the flyer with the activation code, scan it and send that in to verify It's my account. After that they helped me recover the account.
Valve introduced Steam and it's security by Gabe announcing his login and password to the world. You couldn't get in though precisely because of the 2FA.
This was a LONG time ago when things being secure on the internet wasn't a given to most people.
> “Remember the password” barely ever works, even on desktop
Is that for browser or client? I had issue with the browser for the past 6 or so years. Every time I bring it up, a few others mention having this issue but not everyone. I think it's an account based issue since it happens on any device I use. It only happens with Steam and no other site.
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):
if `generateKey` and `publishNewKey` take around ~1s then you'll observe exactly this behaviour - the timestamps will start drifting from some original value.
Scheduling fixed pauses between runs is often better (for jobs where fixed frequency is not critical, which is most of backround jobs) because you then don't have to care whether it will complete within the period.
It is certainly simpler and less fragile than various solutions involving cron-like scheduler and locking (by the way implementation of cron itself is somewhat more complex than it might look like because of exactly this issue).
One thing that somewhat surprised me about typical industrial automation is that running the logic in some variation of do_work(); sleep()/yield(); loop is pretty common (typical modern PLC works that way) and nobody seems to much care about the resulting latency jitter which is from theoretical standpoint totally horrible but in practice insignificant.
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?
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.
To me it's not much a stretch of the imagination that this is what they're already doing, and the time between the scheduled task triggering and setting a new one up might take that much to begin with. The whole setup feels like systems with atd scripts that often rescheduled themselves (possibly based on some condition or using intervals with some variability depending on system load or other such state).
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.
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.
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.
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.
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.
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)
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).
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!
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.
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.
> 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.
> 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.
There is this study back from 2013 (claimed by OP early days of da internetz) which says that out of 1M top sites, 74.5% of those that support SSL/TLS also supported DH/DHE (supported the perfect forward secrecy).
It was a substantial rise comparing to 2006 survey that got 57.5%.
AFAIK the contemporary browser versions preferred DH/EDH as soon as they got them.
The proposition is that the NSA has a large black budget, and it could plausibly have done the math to unwind DH with the most popular 1024-bit DH primes, and certainly would be able to do this for 512-bit DH.
Nobody does this in 2021. Your browser is using X25519 which is the same concept but with Elliptic curves instead of modular exponentiation of integers.
If Steam were concerned about certain TLS parameters, they could just ensure they never agree the worrying parameters. It wouldn't make any sense to instead bake some other mechanism for login and then trust TLS for everything else.
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.
Yeah; I've seen this done elsewhere and facepalmed.
Actually, I've seen this done -worse- elsewhere, where they were actually encrypting the password, using a symmetric key. So if you sniffed the traffic and never loaded the website, I guess, you'd not know the actual password...but you wouldn't need it; it as as good as for the purposes of logging in. If you did load the website, you could still determine what the plaintext password was.
It was really irritating, since I had to figure out what the encryption scheme of a backend app was doing (when I only had access to the frontend code, and the datastore).
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.
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.
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.
That kind of construction involves storing whatever is required for login in plaintext on the backend side. You can get around that limitation by using something like SRP, but that is even more complex than using RSA. On the other hand SRP-like construction would have real security benefits while passing RSA encrypted password over the same channel you got the public key (and implementation of the whole thing) from is of somewhat questionable benefit.
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.
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.
> 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?
The first two points have to do with the fact that if you do the whole process only with symmetric primitives you are only spliting the traditional salted hash into two computations one of which then becomes essentially redundant. If client uses deterministic salt, then whatever you send over the wire is equivalent to password and constant for every authentication. If server sends random challenge which is then hashed by client together with something derived from users password then whatever value that is stored on server in order to check validity of the response is sufficient to fake the response (and also essentially equivalent to plaintext password as it has to be derived from it in some deterministic manner independent of the random salt/challenge). That is to say, the protocol has to be somewhat more complex than that and involve asymetric cryptography to solve both of these issues at once.
There is no technical reason why this could not be implemented in pure JS (and there is lot of things that do something like that with varying complexity and security properties). But there is the question of exactly what is the threat model where the server is trusted to provide implementation of code that defends against compromise of that exact same server.
And as for the UX/UI issue of browser-based security: for security features like this to be truly secure the user has to be sure that he is interacting with the native browser/OS UI and not with something that can be intercepted by JS (or some other untrusted code). This is the reason why various parts of browser UI cannot be hidden, why legitimate permission popups overlap browser toolbar and the idea behind Ctrl-Alt-Del in Windows NT. Such UI by design cannot look as part of your website/application which both confuses even technical users and annoys marketing people because of added friction.
Also what didn't help adoption of any kind of more secure authentication for public facing websites is that in IE the resulting UI was ugly, inconvenient and in some cases downright broken (eg. dialog box used to confirm that you really wanted to use certificate from PKCS#11 token not only didn't say what for, it didn't say anything except “Error! Yes/No”).
> If client uses deterministic salt, then whatever you send over the wire is equivalent to password and constant for every authentication. If server sends random challenge which is then hashed by client together with something derived from users password then whatever value that is stored on server in order to check validity of the response is sufficient to fake the response (and also essentially equivalent to plaintext password as it has to be derived from it in some deterministic manner independent of the random salt/challenge)
You seem to misunderstand the purpose of what I am proposing. I am not proposing this scheme as an alternative to what's proposed in the blogpost.
I am proposing this procedure as an extra protection step for password reuse. If you were to run an exploit on the server that reads its memory contents, you may find a user "Admin" that uses the password "FavoriteFood-DateOfBirth".
If you sent the original version of that password, then such an attacker will find real-world information about you. That information can be used to exploit your identity on other websites. If the password is hashed, then that information doesn't get leaked. Sure, you can fake your authentication to this server, but you have not gained real-world information about your target.
Without salt, the attacker can fake the authentication on every service where that password gets reused. But with salt, every server sees a completely different password on their end. Essentially, your hashed password with salt has become your new password in the server's eyes.
> : for security features like this to be truly secure the user has to be sure that he is interacting with the native browser/OS UI and not with something that can be intercepted by JS
Yes, you were one step further than me on this front. I do agree that communicating this to the user is non-trivial.
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.
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.
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.
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.
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....
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?
> 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.
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.
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.
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.
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?
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