Taskiss wrote:
So, are you saying they don't do it now.. or are you saying they didn't do it before and they're doing it now?
I'm saying there has always been an association between the process running on the game server and the account. Even your description includes that such an association must exist (the "token" you speak of, and if it's kerberos then there needs to be a keytab if you use an authentication server). Where you go after that, well, it's a nice positive assertion but it flies in the face of current events.
Look, this isn't that complicated. It's just a bunch of relational databases. Here is a purely
conceptual example. Obviously the exact details of the implementation may vary somewhat. There are many permutations on this sort of scheme.
In the billing database we have fields like:
AccountID, AccountName, PasswordHash, FirstName, LastName, BillingStatus, etc.
On the authentication server, we have a table mapping AccountIDs to SessionIDs:
AccountID, SessionID
And also a table mapping AccountIDs to CharGroupIDs:
AccountID, CharGroupID, SessionID
On the game servers, we have character records like:
CharacterGroupID, CharName, SessionID, etc.
Now, when you log in to the authentication server, it transmits the username and password hash to the billing server, which looks for a matching account record. If a match is found, the AccountID is returned to the authentication server along with a status code indicating either success or a failure mode (so that the auth server can give you specifics like "bad user/pass" vs. "your account has expired", etc.).
If authentication was successful, the auth server generates a globally unique, ephemeral SessionID, and associates it with the AccountID. It also looks up any existing CharGroupIDs for that AccountID. A token is constructed consisting of at least the SessionID and a list of CharGroupIDs. Possibly it may contain other relevant data like time stamps/nonces or whatever, but that's not really relevant. The token is cryptographically signed by the auth server. This token is then given to the WoW client.
When you connect to a server, you present the token. Because it is cryptographically signed by the auth server, the game server can validate its authenticity. The list of CharGroupIDs it contains tells the game servers which characters that session should have access to. When you create a character on a new server, it generates a new CharGroupID (a globally unique ID so that there can't be collisions), and transmits this and the SessionID back to the auth server so that it can find the related AccountID and make an entry to map the AccountID to the CharGroupID for future sessions. If you log in a second time while you have an active session, the auth server can broadcast a revocation for that SessionID to the game servers, and then generate a new SessionID for your new session. Logging out, of course, releases your SessionID from the login server and revokes it from the game servers.
The point of such a scheme vs. direct authentication by the game servers is that the game servers possess very limited information. Characters are map to ephemeral SessionIDs, which vastly narrows the scope of any exploit involving the game servers. This is important because they have a high surface area for attack. There are many complex interactions between the WoW client and the game server, and a flaw in any of them could potentially allow data leaks or even remote execution. It is therefore important that the game servers not only do not
possess sensitive account information, but that they do not even
have access to that information. Moreover, if multiple game servers are compromised by the same agent, they cannot "compare notes" to determine that certain characters on realm A are controlled by the same account as other specific characters on realm B.
In the mean-time, the auth server's communication with the WoW client and the game servers is accomplished through a very narrow API which makes it much easier to secure to high degree of confidence. And, even supposing that it could be compromised somehow, the most an attacker would gain would be AccountID -> CharGroupID mappings. Let's just assume that this further enables them to obtain character names as well. But still, the AccountID is at least an "anonymous" number. While the auth server
uses usernames during login, it doesn't
store that data.
Of course, the attacker could snoop usernames and hashes from incoming authentication attempts (which would be seriously bad for anyone without an authenticator) but at least they wouldn't be able to mine username and real life data from the billing database without further compromising
that API, which is at least an equally daunting task.
Now, it is possible that Blizzard dispensed with the SessionIDs, and the access token granted by the authentication server basically consists of a signed AccountID and some kind of nonce to prevent replay attacks by a malicious client. This would offload the AccountID -> CharGroupID mappins to game servers. While this is less secure, it would at least still prevents a hostile WoW client or a compromised game server from obtaining sensitive data like usernames, billing addresses, etc. It would introduce some potential issues ("comparing note" as I mentioned above), but these may be deemed minor enough to be acceptable. One potential upside is that it make it easier for characters to be created while the authentication server is down, but that's kind of an edge case to begin with. It would also somewhat reduce CPU and bandwidth requirements for the auth server, but I doubt that's a major issue. On the whole, we're still talking about small amounts of data transmitted only at login/logout and character creation/deletion. I will note that if you delete your WoW config and ask it to recommend a realm to you, it will recommend the realm that you have the most characters on. This implies that the auth server is maintaining a mapping of AccountID -> CharGroupID or CharIDs, rather than the game servers themselves, which would fit with the original scheme I outlined above.
So again, I don't know
exactly how Blizzard has implemented their account authentication system, but I can virtually guarantee you that they've compartmentalized their data in some similar fashion. To do otherwise would just be ... insane. Blizzard has to know that the game servers are filled with people actively trying to exploit and otherwise **** with them. Giving the game servers access to any more account data than the bare minimum they need to do their job would be major security no-no.
And there's the rub with Real ID. Real ID breaks this anonymity in a major way. We can imagine a number of different ways that Real ID could be implemented, but the details are mostly irrelevant. What is relevant is that real name data is made available to the WoW client through at least the Lua API, and probably on a deeper level at the even less documented client/server communication level. In short, the game server becomes -- at a
minimum -- a
relay for real-name-to-character mappings.
This is why I say that Real ID broadens the scope of a game server exploit. To answer Wwen's point, yes, any time you make a purchase or otherwise provide real-life data to a remote computer system, you're taking a security risk. But it's a
measured risk. A properly secured billing server would be very difficult to compromise. Blizzard initiatives like the authenticators have lead me to believe (at least in the past...) that Blizzard does have a pretty solid grasp on security implementation. Thus, allowing the billing servers to store/access real name data is entirely different proposition than making that data available to the many game servers. It's purely a question of surface area and the basic reality that the game servers are exposed to direct communication with outside agents that must be presumed to be hostile.
Login
Register
FAQ
Search
