How MTGATracker verifies your identity in MTGA, or, MTGATracker's Model of Trust
note: this is a draft for the yet-to-go-live MTGATracker blog
tags: tech, discord, js, inspector
Recently someone asked in discord for more details about how hashes are generated for scoutmaster / forum posts and why. This seems like a decent topic for a technical blog post, so, behold! Here's a complete breakdown of the entire ID verification process for Inspector, all the way from first game to logging in. (Note: for the purposes of this post, we'll assume that users do not have incognito mode enabled, which disables inspector completely.) Let's call the user for this demonstration Gemma. Let's also imagine up a bad actor who is trying to "hack" into Gemma's inspector account & steal her crazy cool decklists; we'll call him Spike.
Step 1: Gemma completes a game with MTGATracker running
When you complete a game with MTGATracker running for the first time, a few things happen in the background on our API. First, we create a new user record for you in the inspector database based on the MTGA username that just completed the match that MTGATracker observed. (This is important later on!) This database record is where we'll keep certain settings for your account, but not a lot else. For example, if you have any decks hidden in Inspector, we'd keep track of that there. Next, a game record is inserted into the database as well. These are both required for a user to log in to inspector for the first time.
We make this happen by sending an HTTP request from the MTGATracker desktop application to the MTGATracker API, which is served by Auth0_Extend / webtask.io.
Step 2: Gemma joins our discord
When you join our discord, our robot sends you instructions on how to verify your discord account. Since discord is completely free, is super easy to make an account for, and allows duplicate usernames, we must assume that Spike is also making discord accounts attempting to impersonate Gemma. So let's say Gemma makes an account, and ends up with the discord username Gemma#1234. Spike also creates a discord account, and ends up with the username Gemma#9876. They both immediately start telling us in discord that they both own the MTGA username Gemma. Who do we believe? We'll solve this issue in the next step:
Step 3: Gemma posts on the beta forums
Since Gemma is the only person who knows Gemma's MTGA Beta Forum password, and since the MTGA Beta Forums do not allow duplicate usernames, when we see that the MTGA user Gemma has posted something on the beta forums, we can believe that it is actually Gemma and not an impersonator. Gemma will also know that her actual discord username is Gemma#1234, so if she posts that username in the forums, we now have proof that the actual Gemma is Gemma#1234, and that Gemma#9876 could be Spike, her dastardly impersonator. If Gemma lets us know that the other account is not hers, we will know to ban it from the MTGATracker discord server immediately.
But what if Gemma doesn't want to share her discord username to everyone in the MTGA Beta Forums?
Errata: Step 3B: Scoutmaster hashes Gemma's discord ID
That's where those wacky strings people post on the forums come in. When Gemma originally joined our discord server, Scoutmaster (MTGATracker's verification bot) generated and sent to Gemma what is called a cryptographic hash of Gemma's discord ID. A cryptographic hash is a deterministic numeric representation of a piece of data, that generally cannot be reversed (without either a lot of CPU power, or a lot of time). The specific algorithm used isn't that important, but I'll at least say it isn't MD5 ;) Furthermore, because it is a hash of an ID that is only visible to Gemma's friends on discord, or members who share a server with Gemma, it is even more robust to cracking attempts from outsiders.
Note: an earlier version of this process used some false assumptions and allowed users to post the first letter of
their discord username, followed by the last 3 numbers of their discriminator. (In this example, that
would have been
G*******234 .) This preserved privacy
by not revealing the entire username, but makes some false assumptions that lead to it being insecure.
First, it assumes that the first letter of a discord's username and the last 3 digits of the discord "discriminator"
would be unique enough to identify a user. We actually never ran into
any collision issues with this method, however, it was brought to our
attention resonsibly & privately by a security researcher that discord discriminators are actually
changeable for premium discord users, therefore making it trivial for a
permium user to impersonate someone if they managed to make an account and change
their descriminator between steps 3 and steps 4. This was reported to us on Friday 6/1, and
was resolved the following Monday, 6/4.
Step 4: Scoutmaster checks the forums for new tracker scouts
Using a series of browser automation tools such as headless chrome and nightmare.js, Scoutmaster is able to read the forums. (Scoutmaster is also very anxious to get news about the Kaladesh & Aether Revolt patch, after all). Whenever Scoutmaster sees a new post, it searches the post for a few patterns--we accept posts that contain a user's entire discord username ("Gemma#1234"), or the cryptographic hash from earlier. Scoutmaster finds the pattern & saves it for later. Then, since scoutmaster shares a server with Gemma, when scoutmaster iterates over all the users it knows, Gemma will be in the list. So, scoutmaster loops over that list, hashing each user's discord ID's with the same algorithm it used the first time (or, in the case of a simple full username, it just looks for a simple match). When it finds a match, scoutmaster knows it has found the correct discord ID to map to the user who posted in the beta forums--and it manages to do this without revealing the username Gemma#1234 to anyone who is not also in the discord server!
Spike is of course still up to his dastardly ways, and is still trying to get into Gemma's account. Spike could log in
to MTGA forums and post a message trying to fool us. Let's say Spike has even gone to the lengths of making an
MTGA account similar to Gemma's, with the username
DefinitelyGemma . When DefinitelyGemma posts this on the forums:
"Hi, I'm MTGA user Gemma and my discord username is Gemma#9876"
Scoutmaster actually won't even look at the rest of the message besides the discord username. Gemma#9876 will get access to DefinitelyGemma, and DefinitelyGemma only, since the only thing we care about when it comes to the MTGA username is who posted the message. Spike is thwarted yet again and will have to keep running his own netdecked, far-from-tuned UW Control.
Note that Scoutmaster does it's best, but isn't perfect. When Scoutmaster gets confused, it sends a message to the mod team (including a screenshot of the forum post) for humans to follow up on. This was a fun challenge to solve; if you're interested in seeing the nightmare.js source that made this happen, get in touch with @Spencatro!
Step 5: Gemma logs in to Inspector
When Gemma puts her MTGA username into the login page at Inspector, it sends a request to our API letting us know that Gemma wants to log in. The API then looks up Gemma's discord ID, assignes her user a 2-minute access code, and uses discord.js to send it to her discord account. She then has 2 minutes to put the code in and log in.
If Spike visits the same login page and enters Gemma's username... Gemma still gets the token. If she gets many requests like this, it may be obvious that someone unauthorized is attempting to access her account. At this point, MTGATracker maintainers could in theory launch an investigation to find out where Spike's requests are coming from, and ban that address (and any users making requests from that address) from all MTGATracker systems--though, we certainly hope this never progresses past "in theory."
I hope y'all find this post informative, if not interesting. MTGA data isn't exactly on the level of importance as credit card numbers or home addresses, but we take our data & security practices seriously anyways. If you're a security researcher & think you've found an exploit or flaw with this model of trust, please contact us at email@example.com .