Skip to content

Instantly share code, notes, and snippets.

@vcokltfre
Created February 3, 2022 19:46
Show Gist options
  • Save vcokltfre/c9a7760798f900919d575c93f1d08fc4 to your computer and use it in GitHub Desktop.
Save vcokltfre/c9a7760798f900919d575c93f1d08fc4 to your computer and use it in GitHub Desktop.

I see a lot of people talking about Discord's use of tokens these days due to the large quantity of phishing attacks going around. With this discussion comes a lot of false assumptions and misconceptions about tokens, which I hope to clear up a bit in this gist. Note that this primarily refers to the specific situation that the user has downloaded token stealing malware as a result of the scam.

First, some common complaints I see:

  1. Tokens are insecure because they bypass 2FA
  2. Tokens are insecure because aren't encrypted at rest
  3. Tokens could be locked to an IP, but they're not, which is a bad design

Tokens are insecure because they bypass 2FA

Tokens are on a fundamentally different level of the stack than 2FA for security. Tokens are a step after 2FA, and to compare both is unfair, as they serve different purposes. Think of tokens as a sort of "session" that a user has. This session means they don't need to enter a password and 2FA code on every API request they make. 2FA is used during the process of acquiring this session, to ensure that a session can only be gained by a user who is permitted to do so. Without tokens 'bypassing' 2FA you'd need to enter a 2FA code and password every time you make a request to the API - which is a lot.

Tokens are insecure because aren't encrypted at rest

While it's true that unencrypted tokens can be accessed eaily, it's also true of encrypted ones. An electron application is not very hard to inject malicious code into if you already have malware on someone's PC, and at some point in that app the token must be decrypted. In the end you've added a layer of security, but it's still not very secure, that's just the nature of the type of application.

Tokens could be locked to an IP, but they're not, which is a bad design

There's two parts to this one:

  1. Convenience. Having tokens locked to a specific IP is great, but only if you have a static IP, which few people do. The issue arises with dynamic IPs. Many ISPs rotate IPs fairly often, sometimes every 24 hours. For some people it may seem fine to log in every 24 hours, but for the majority it's too prhibitive. It gets worse when you consider mobile devices that may be connecting to WiFi and mobile networks multiple times per day, being given different IPs each time.

  2. It still doesn't actually solve the problem. So, you've managed to convince discord to ignore point 1 and implement IP locking to tokens, you now move on to the next challenge: the scammer already has access to your PC via the malware, what stops them using it for command and control instead? No matter what you do, there'll still be a workaround that removes the added security.


The issue, I hope I have made clear, is not a technical one, but rather one of user education. As long as the scammers have access to your PC they will be able to control your account by one method or another. The only way we can reasonable fight scams is by educating people, and this needs to be done at various levels, which are likely a long way from actually being done:

  1. Discord - and other companies - at platform level need to start giving users advice and information about how to stay safe from these scams.

  2. Schools need to teach students far more about things like phishing. There's a basic level of education about this, but there's an unacceptably low amount actually taught about this. The curriculums teaching this were created a decade ago when threats were different, but times change, scams change, and what we teach people needs to change too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment