[HN Gopher] Steam's login method is kinda interesting
___________________________________________________________________
Steam's login method is kinda interesting
Author : zertrin
Score : 322 points
Date : 2021-01-11 15:27 UTC (6 hours ago)
(HTM) web link (owlspace.xyz)
(TXT) w3m dump (owlspace.xyz)
| sroussey wrote:
| 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
| sroussey wrote:
| Repeat from a couple days ago:
| https://news.ycombinator.com/item?id=25690995
| hutattedonmyarm wrote:
| I posted even earlier:
| https://news.ycombinator.com/item?id=25684254
|
| But I'm happy to see it got some attention after all!
| cafed00d wrote:
| 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.
| bArray wrote:
| 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 wrote:
| > 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 wrote:
| I thought ECDHE or X25519 suites were pretty common these
| days; I appear to get the latter when connecting to
| Cloudflare hosts for example.
| [deleted]
| bArray wrote:
| > 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.
| johncolanduoni wrote:
| Apparently TLS 1.3 only supports cipher suites with
| ephemeral key exchange:
| https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/
| mxscho wrote:
| 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.
| jordache wrote:
| This is clearly a violation of security good practice tenet of
| not implementing novel patterns.
| qorrect wrote:
| > The internet was a different place though in the early 2010s
|
| Oh how far we've come. /s
| Taylor_OD wrote:
| Uber didnt exist in early 2010.
| qorrect wrote:
| Pirate Taxi's have existed for decades, the mobile app for
| them did not yet exist.
| syoc wrote:
| There was some discussion on /r/netsec where this was published
| as well.
| https://www.reddit.com/r/netsec/comments/ksn6rc/steams_login...
| T3RMINATED wrote:
| zis is a blog by some german nerd.
| RexM wrote:
| 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.
| simongr3dal wrote:
| I'm just annoyed that Steam still doesn't support standard TOTP
| two factor but uses either an email code or their app.
| kuroguro wrote:
| 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 wrote:
| 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
| kuroguro wrote:
| > 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 wrote:
| 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!
| mschuster91 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| Cthulhu_ wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jrochkind1 wrote:
| So... what _is_ any better?
|
| I mean, I guess, hiring you to find vulnerabilities, is the
| pitch.
|
| I'm curious whether your team would have found this kind of
| steam vulnerability.
| sjtgraham wrote:
| I haven't read the article I'm just joining in on the
| side-discussion in this thread.
| lol768 wrote:
| > 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.
| sjtgraham wrote:
| 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.
| xvector wrote:
| 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.
| lol768 wrote:
| > 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.
| sgtfrankieboy wrote:
| Which bank? It's a 70/30 between ING and Rabobank for me.
| hkolk wrote:
| Rabobank was the one with the horrible non-native client so
| pretty sure he is talking about ING :)
| bulgr0z wrote:
| 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.
| spockz wrote:
| There are many ING apps in the marketplace. Almost one
| for each product type and country. The comments above
| refer to the Dutch version.
| tdons wrote:
| https://www.security.nl/posting/34165/%22Beveiliging+ING+mob.
| ..
|
| > "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"
|
| Assuming SRP refers to this https://en.wikipedia.org/wiki/Sec
| ure_Remote_Password_protoco...
| leokennis wrote:
| 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.
| zemnmez wrote:
| 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.
| TimTheTinker wrote:
| True, but for those reading: this is a knock on roll-your-own
| crypto, not on application-level crypto or the defense-in-
| depth benefits it can provide.
| saagarjha wrote:
| SSL pinning and other MITM obfuscations are frequently not
| very useful from a security perspective.
| faeyanpiraat wrote:
| Are you sure the percentages are correct?
| pc86 wrote:
| 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).
| slightwinder wrote:
| Switching-Cost in Europe is around low to zero. Especially
| with discount-banks like ING, who are offering free
| services.
|
| Bank-hopping is also simple and having accounts with
| multiple banks was common for certain people some years
| ago.
| gpvos wrote:
| Note that in NL, ING is _not_ a discount bank.
| meetups323 wrote:
| 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.
| slightwinder wrote:
| 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.
| seanalltogether wrote:
| 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.
| throwaway09223 wrote:
| 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.
| bricss wrote:
| It seems to me that whoever wrote this article has no idea what
| an MITM attack means.
| txr wrote:
| This exact procedure is used for the pidgin plugin:
| https://github.com/EionRobb/pidgin-opensteamworks
| thoughtsunifi12 wrote:
| delete thoughtsunufic account
| noobquestion81 wrote:
| 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.
| yuliyp wrote:
| 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.
| gruez wrote:
| 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.
| est31 wrote:
| You might be "only" admin of such a MITM box and can maybe
| only see/search the decrypted contents but not alter them.
| lights0123 wrote:
| For sure, but it's at least possible for them to set up a
| honeypot to detect that.
| gruez wrote:
| Yeah that prevents mass surveillance but doesn't prevent
| targeted surveillance (think steam account with valuable
| skins).
| [deleted]
| nijave wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ROARosen wrote:
| True, except that in Steam's specific case, they are
| actually using SSL.
| merb wrote:
| > 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.
|
| how does ssl prevent you from that? it doesn't.
| drodgers wrote:
| 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.
| woodrowbarlow wrote:
| 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.
| mlyle wrote:
| Those geographically distributed SSL-terminating load
| balancers could still conduct such an attack, SSL or not.
| jaywalk wrote:
| Yep. If any sort of MITM attack was their motivation for
| this, they didn't really think it through.
| crdrost wrote:
| 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.
| rplnt wrote:
| 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...
| BlueTemplar wrote:
| I wonder what did they use between 2003 and 2012 ?
| superkuh wrote:
| It's not listed anywhere on his site but by random guessing of
| URLs I found his RSS feed: https://owlspace.xyz/index.xml
| MayeulC wrote:
| If you want fancy password-based authentication without
| transmitting it, have a look at PAKE (and OPAQUE):
| https://news.ycombinator.com/item?id=18259393
| netsharc wrote:
| 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 wrote:
| 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 wrote:
| That only works if the string is the same each time. But it
| won't, if it changes like TOTP code.
| k1t wrote:
| If all you are comparing is HASH(random_string +
| hashed_password) then it will still work.
|
| The server will give me random_string and I know
| hashed_password from the DB leak.
|
| Obviously this assumes the login process actually works as
| described in the earlier post.
| lostmsu wrote:
| That protects hashes from leaking in transit, for the
| scenario with 3rd party TLS terminators mentioned above.
| jarkhen wrote:
| If the string changes each time, how could they possibly
| have the matching hashed password stored in the database?
| fgonzag wrote:
| 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 wrote:
| 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.
| SAI_Peregrinus wrote:
| Except that it's easy (indeed, required for security) to
| change the nonce for each login request, so you can't
| just replay the hash.
| jarkhen wrote:
| That protects against an attacker reading network
| traffic. It does _not_ protect against an attacker that
| has the hashed password from the DB.
|
| The only thing you need in order to authenticate at any
| given time is the hash of (hashed password + nonce). The
| latter you get _for free_ , at any time, from the server,
| so you only need to know the hashed password -- not the
| password itself. Since the hashed password is directly
| stored in the DB, if you get your hands on that you can
| authenticate.
| lostcolony wrote:
| 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).
| lxgr wrote:
| Coincidentally, that is exactly what MS-CHAPv2 does if memory
| serves me right.
| [deleted]
| madisp wrote:
| 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 wrote:
| 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 wrote:
| Or, you could (re)schedule first and then generate the key?
| Assuming that key generation doesn't take an hour, of course.
| :)
| madisp wrote:
| 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?
| yuliyp wrote:
| 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.
| aasasd wrote:
| 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.
| eat_veggies wrote:
| 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
|
| https://github.com/steamguard-totp/steamguard-shared-secret
| MayeulC wrote:
| 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.
| jannes wrote:
| Unfortunately, you can't use Steam Guard without a phone
| number.
| mhh__ wrote:
| My steam account is worth more than my computer, I'm quite
| happy that it's hard to steal.
|
| I also don't have to log in every time I use it, that's not a
| steam-problem.
| Aardwolf wrote:
| One issue: if you lose access to your email, you also lose
| access to your worthy steam account, since it emails a code
| every time
| wnevets wrote:
| Doesn't the steam mobile app provide access codes?
| [deleted]
| elliottcarlson wrote:
| It does
| Aardwolf wrote:
| How does that one authenticate itself then?
|
| (NOTE: I didn't even know the PC gaming service steam had
| a mobile app ;))
| stevewodil wrote:
| For me, when I download Steam Authenticator it's tied to
| my phone number so the first time I login it will send me
| a text message code, and then from there it generates the
| authenticator codes in app
| wnevets wrote:
| Well in the scenario where you lose access to your email
| address you would theoretically still have access to your
| phone with the steam app already installed and
| authenticated
| [deleted]
| brandon wrote:
| Email access is required for _self-service_ account
| recovery, but there are plenty of other documented methods:
|
| https://support.steampowered.com/kb_article.php?ref=5421-QT
| F...
| WorldMaker wrote:
| 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.
| WorldMaker wrote:
| 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.
| zepearl wrote:
| > _"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).
| devrand wrote:
| 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.
| benhurmarcel wrote:
| I would absolutely disable my access to that community market
| if it meant I could use a regular TOTP.
| Kaze404 wrote:
| > 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.
| aasasd wrote:
| > _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.
| Kaze404 wrote:
| Wow, that sounds like an interesting read. I'll see if I
| can track one of those books down, thanks!
| aasasd wrote:
| 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.
| baud147258 wrote:
| 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?
| thedmstdmstdmst wrote:
| 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.
| leokennis wrote:
| Actually, when using Steam on macOS, it feels like traveling
| back to 2005.
|
| I like Steam, it's convenient and it works, but I don't think
| "being ahead of the curve" is in their dictionary.
| Kaze404 wrote:
| 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.
| Wowfunhappy wrote:
| How often do you log in?
|
| My experience is that a lot of this stuff works really well
| if you're using Steam regularly, and completely falls apart
| if you use it once a month.
| Kaze404 wrote:
| Interesting. I definitely log in daily, I have Steam set to
| auto-launch because of Remote Play.
| e_proxus wrote:
| It also logs you out as soon as you enable a VPN connection
| (to a different cpuntey/IP?) while running.
| mrlala wrote:
| Yeah exactly, I have steam on 5 computers at home here
| between kids and myself that are used all the time.. rarely
| is anything logged out unexpectedly.
| Nullabillity wrote:
| 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
| birdyrooster wrote:
| I had to remove and reinstall Steam to get my auto login
| working again
| nonsince wrote:
| 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.
| dkersten wrote:
| Did they ask for much to verify it was yours? Given what you
| said, I guess not?
| utf_8x wrote:
| 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.
| dkersten wrote:
| That actually seems like a pretty reasonable solution, in
| your particular case.
| kamyarg wrote:
| Download the mobile app, they have an option to enable OTP
| pushes, when I login my phone gets the code directly in
| notifications.
|
| I also was annoyed by email code thingy until I found this
| recently.
| blackearl wrote:
| How often are you logging into Steam? The app stays logged in
| for me pretty much forever
| _jal wrote:
| 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.
| dfabulich wrote:
| 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 wrote:
| 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.
| kbenson wrote:
| 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.
| [deleted]
| dfabulich wrote:
| The website _definitely_ has a crazy short session length
| (it can 't be more than 48 hours, probably substantially
| less).
|
| I do login to the website more often than I do the native
| Steam app, typically to wishlist games that I see linked
| from other web sites.
|
| I wonder if logging into the website invalidates all of
| my sessions after however many hours.
| Wowfunhappy wrote:
| > Does the Mac version of Steam install through the Mac
| App store
|
| It does not, and I can't see it ever being allowed there.
| It's quite literally an alternate app store!
| kbenson wrote:
| 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.
| jonathanlydall wrote:
| Compromising of game accounts with real world monetary value is
| very much an industry, one with competition, customer service,
| supply chains, etc.
|
| Source: I used to do customer service for Blizzard and a large
| part of our work was dealing with accounts compromised by gold
| sellers.
| aimor wrote:
| _"Remember the password" barely ever works_
|
| This has been my experience too. I still check the box every
| time I log in.
| nirushiv wrote:
| How does this work implementation wise? One private key per
| application? Per user? Or refreshed on a per-login basis on the
| first POST?
___________________________________________________________________
(page generated 2021-01-11 22:00 UTC)