[API] Bot MFA/Two Factor

[jhgg]

On June 17th, 2016 - bots will start considering their owner's two factor status on servers with two factor authentication enabled, meaning, they will be unable to perform functions which require "elevated" permissions functions on servers with two-factor authentication enabled until the application owner turns on two factor on their account.

As an example:

Server A turns on two factor. This means that all regular users will be required to enable two factor on their accounts before they can perform functions requiring "elevated" permissions. Bots obviously can't have two factor, so we continue to allow bots to perform these functions on these servers. However, after this change, we will consider the two factor status of the account that owns the bot to check whether to allow the bot to perform these actions on a server with two factor enabled.

If your bot does not require these permissions, or the server does not have two factor on, your bot is unaffected. If the owner account does not have two factor enabled, and the bot tries to perform a function which requires "elevated" permissions, it will not be able to until the owner account turns on 2fa. Other than that, the bot should still be able to do everything else that does not require the "elevated" permissions.

The following are considered "elevated" permissions:

• KICK_MEMBERS
• BAN_MEMBERS
• MANAGE_CHANNELS
• MANAGE_GUILD
• MANAGE_ROLES
• MANAGE_MESSAGES
• ADMINISTRATOR

For more info about how two factor works on Discord, check out the blog post: https://blog.discordapp.com/keeping-discord-safe-and-sound/ and the support article: https://support.discordapp.com/hc/en-us/articles/219576828

[cookkkie]

👍

[freyacodes]

I take it that I'm the only person here who doesn't use a phone on a regular basis? Guess I'll have to change that.

[zet4]

@Frederikam you could always use Authy or WinAuth.

[Nanabell]

hmm im not a fan of it. As suggestion make it Possible to OptOut of this (only as ServerOwner ofc) ?

[freyacodes]

Thanks @ZetaHunter. WinAuth was just what I needed.

[MinnDevelopment]

What do you have to change for client api login? I assume you have to add a field containing an auth code to the request body?

[freyacodes]

Thanks for reminding me that I ripped my selfbot. I found how to authenticate with the code.

Edit: Removed because apparently automating this will get you banned.

[zet4]

To generate code you need to use TOTP library with the secret you obtain when you first enabled mfa (the one you can "manually input"), here are libs for some languages: Java, Python, C#, Go

[din0s]

I was able to generate my 2FA key for Java using this lib. For anyone interested ^.^

[vishnevskiy]

This does not mean the bot have to use 2 factor, it just means the owner of the bot has to have 2 factor. So no one can steal your account and steal your bot.

[freyacodes]

@vishnevskiy but we are talking about selfbots, not just regular bots.

[jhgg]

Self bots aren't supported. You shouldn't be going through the 2FA login flow on your bot either. Log in on the client, grab the token from local storage and use that token in your self bot.

Do not call /api/login or /api/auth/mfa/totp.

I repeat. Do not call /api/login or /api/auth/mfa/totp. If you are using a self bot on a 2fa enabled account, and you are automating the login and mfa flow. Your account will get banned. Instead, log in on the discord client, pop open the web inspector, (ctrl/cmd shift I), and type localStorage.token in the console to get your auth token. Pass this to the bot library instead, like you would a bot token. discord.py supports this as client.run('mfa.theTokenHere', bot=False).

Do NOT automate calling /api/login. and /api/auth/mfa/totp Your account will get banned.

I'll refer to my earlier Q&A:

Q: What about smaller/private bots? Bots that are hosted on my own user account that I use discord with. Will you ban those? A: If they become a problem, yes. Be smart and use an official bot account.

Automating the MFA flow constitutes as a problem. Do not do it.

[meew0]

Is it allowed to automate calling /api/login for non-2FA enabled accounts?

[AlexFlipnote]

Or why not just deny self bots at all cost.... Making a test bot ain't that bad?

[jhgg]

Is it allowed to automate calling /api/login for non-2FA enabled accounts?

We won't ban for it. But it's strongly discouraged. Use tokens.

Or why not just deny self bots at all cost.... Making a test bot ain't that bad?

We're not interested in banning self bots. Some users use them to do cool things. However, if your self bot does stupid stuff (like spams the API due to a bug in your code), we're much less forgiving than we would be if you were using a dedicated bot account. Like I said earlier, be smart and use a bot account. Self bots are not supported. Use them at your own risk (or demise!). Additionally, self bots should not act like actual bots, i.e. they shouldn't respond to other people's commands, join servers on your behalf, etc... And they definitely shouldn't do anything that's considered abuse of API for official bot accounts either.

[metagn]

We won't ban for it. But it's strongly discouraged. Use tokens.

so cache?

[jhgg]

Yes. Cache the token. I think we discussed this on the API server a few months ago.

[metagn]

yea a long time ago but got a little confused there, thought you meant something else

[freyacodes]

@jhgg would it be acceptable behaviour to have a selfbot log in with a given TOTP code (sent by REST, DM or some other means)? This way two factor authentication is still in the hands of the user. Or is the only way we can use the /api/auth/mfa/totp endpoint with an official Discord client?

[jhgg]

/api/auth/mfa/totp is an endpoint for the official Discord client only. Do not call it from a bot or script. Use a token that's generated via the official client to log into a self bot.

[meew0]

Could custom clients use the endpoint? Previously you said that it cannot be automated, now you said that it's for the official client only; what of the two is it?

[devsnek]

Can we automate the process of getting a generated token from the official client?

[DV8FromTheWorld]

Considering JDA-Client is aimed at support Custom Client stuff, not SelfBots, we have 2FA stuff. As a note, the 2FA isn't automated. You have to get the 2FA time-sensitive code from an Auth app like Google Authenticator and put it in just like as if you were on a client. JDA-Client actually has 2 users who are in preliminary stages of writing their own Client projects, so this is a crucial part. (Just wanted to make this public now instead of you seeing weeks/months later and being upset then)

[jhgg]

Like I said earlier. Do not call /api/login or /api/auth/mfa/totp.. If you want to implement this on your library, I can't stop you. But you are putting your users at risk. We specifically do not want it implemented as in the future we may decide to implement additional security measures on these endpoints, which may consider bots/scripts an attack on the login, which the system may automatically respond by locking the account, banning the IP that's trying to log in, etc... This isn't meant to stop bots, but to stop people from trying to brute force passwords, mfa codes, etc... Additionally, creating a login from an mfa token is more expensive on our end than a regular login. If your bot library gets in a loop logging in, generating a token and crashing (which it's happened before) we will ban the account. I see no reason why a user using a custom client can't grab their token from the official client.

[DV8FromTheWorld]

I see no reason why a custom client can't login in the same fashion as the currently client, especially if tokens are cached so that login need not occur again after a token has been successfully acquired. I suppose though, at the end of the day, it is H&C decision on what is considered right or best.

I suppose I'll put a warning message to users who want to login with their email and password like they do on the client.

[DV8FromTheWorld]

As a note though: If someone is trying to brute force a password or mfa codes, whether or not this is implemented into a library isn't going to change that all that much. The endpoints still exist. If they truly care they much, they'll attempt to brute force using their own REST wrapping. Furthermore, if they were really serious about it they would be jumping from IP to IP, so it seems that banning the IP or even worse, the account, just for using an endpoint in a perfectly valid and non-harmful way seem to be pointless and almost detrimental to your users.

[AraHaan]

Here is the Question How can the BOT OWNER TURN ON 2FA if they DO NOT have a phone. I think it would be great to have a fallback to EMAIL option as well so that way you can ACTUALLY turn it on so that way there is no issues. OR if they do NOT have a phone give them a form that lets them set a pin on their account to enable it too.

[mnlkrs]

you could always use Authy or WinAuth.

[AraHaan]

But then again account pin codes would be nice as well before it lets you login. :stuck_out_tongue:

[freyacodes]

Why would you need another password which is numeric? 2FA should be plenty to keep your account safe.

[AraHaan]

But it does horible if they have no phone, I sadly cant turn it on in the App itself because rn it only asks for phone which sucks.

[metagn]

Its not only for the phone, there's apps for it on the desktop like Authy and WinAuth lol

[abalabahaha]

As explained already, there are TOTP generators for desktop OSes (Authy, WinAuth, oath tool, etc.) in addition to mobile apps. There are also 10 regeneratable backup codes you could use.

[freyacodes]

https://winauth.com/

[AraHaan]

yeah I just found it now if only the discord app Mentioned that "For Microsoft® Windows® Operating Systems use WinAuth." Or something like that so people that use windows can find it.

[metagn]

i mean it says "win" in the name dude

and authy works on windows too iirc

[DV8FromTheWorld]

Is there a way to determine, using only information of the logged in bot, if the account which owns the bot has 2FA enabled? I'd rather write pre-checks (like I do with cached permissions) when working with functions that require Elevated-Permissions instead of passing it off to Discord and doing post-checks.

[jhgg]

@DV8FromTheWorld it will be in the ready payload, under the user object.

[jhgg]

also as a reminder - this comes out tonight.

[DV8FromTheWorld]

I wish that changes like these could be launched on a test gateway like a day or 2 before, so we can test and implement support before they are completely live. Especially since you say its going to be in the READY packet, building and testing against that system would be nice. Similarly to how we could use gateway v4 and implement and work on v5 without that going live immediately, so that we'd have time to put support into the libraries.

[jhgg]

it's a field in the user object. if your code crashes because we add an additional field somewhere, you are going to have a bad time... i'd understand if we removed a field and something crashed... but adding a field should be a 💯 % backwards compatible change...

[jhgg]

As a note, we will probably document what we consider breaking/non-breaking changes - and are working on implementing API versioning. But, adding a field to an object will never be considered a breaking change, and is something we will do from time to time with no prior warning. If your code breaks because an additional field is introduced into a response from our servers, you should write your code in a way that doesn't. We won't change type of, or remove existing fields w/o a bump in API version.

[AraHaan]

What is the current version rn?

[jhgg]

There is no version right now.

Also, this change should be going out tonight.

[jhgg]

Closing this as it's been released for a week now.

[einsteinK]

Related to not being allowed to automate: We're still allowed to "automate" loging in using 2FA, as long as getting the code isn't, right? Basicly, I have my bot first login, see if it requires MFA, and if it does, ask the console for a code. I'm pretty sure that's allowed, but, just in case, asking it here.

[metagn]

I don't think so, you shouldn't login every time you start the bot, cache the token somehow (this applies regardless if your acc is 2fa or not)

[einsteinK]

How long is the token valid, though? For now, I did take the token from the Dev Console.

[metagn]

Until you change your password/your 2fa token changes

[AraHaan]

Or if it is a bot account until you invalidate the token and regenerate a new one.