Search the Community
Showing results for tags 'authentication'.
Found 2 results
Hereby I would like to present you my Discord Bot "DU-auth" for each Discord Server. The users of a discord with "DU-auth" can authenticate themselves with their Dual Universe Board Profile. With this bot, fakers and cheaters have no room. Facts about the bot: - Users only need two steps to authenticate themselves. - Server owners only need three simple steps to install the bot. - Auto check of changed names (enable or disable). - Many admin commands to configure the bot. - Define the role for authenticated users. - Define the channel for commands. - Create private welcome message (enable or disable). - Users only have to authenticate on one discord with "DU-auth", then they are also authenticated on other servers. - Needs only minimal permissions. More information: https://sites.google.com/view/du-auth Try it now on my test Discord server: https://discord.gg/GZ8u5UG greetings CodePeon
Hello explorers, I see more and more communities and organizations setting up authentication based on Dual Universe account in order to identify players on Discords, websites or other places outside the game. However, it's not a simple process and there are lots of potential security breaches (I've seen and reported a few). Thus, I decided to write this post where I describe good security practices and point some common attack scenarios. While this post is mostly directed towards developers and webmasters, I think it's also a good and interested read for all players. How authentication works Currently, Novaquark doesn't provide any way for third party applications to identify a player (they have other priorities like creating the game for now). So, how to do it then ? Usually, we rely on authenticating a player on the third party application via standard login/password authentication and then give to the player a random token he must show on his/her profile. In other words, the authentication process works using the following steps: The player create an account on the third party application. The third party application generates and gives a token to the player (ex: "my-app-auth:396943934983749839"). The player logs into his Dual Universe account and updates his profile, appending the token. The player tells the application that token is uploaded on his profile (specifying his/her profile name or URL). The application browses the profile, read the player name and public information (organizations, titles, etc.). It also double-check that the token is present and correct. The application then "links" the local account to the player profile and may autorise access to restricted content. When security fails This list is not exhaustive, but contains most problems I've seen or can think about. For easier reading, I put in red the attack scenario and in green the good practices you should use/see. 1) Token randomness A secret must be random! Else, someone could just predict or guess the token and use it on his/her own profile. Standard random() functions provided by languages are actually not random and may present collisions: you can predict their output (see https://medium.com/@betable/tifu-by-using-math-random-f1c308c4fd9d if you don't trust me). Thus, it is important to use strong random generators like: java.security.secureRandom() for Java random_bytes() or openssl_random_pseudo_bytes() in PHP crypto.randomBytes() for NodeJS secrets.token_bytes() (or secrets.token_hex()) in Python Etc. 2) Your token is actually public! Yes, the token is public: you put it on your public profile as the application needs to read it. A hacker could read it when you update your profile and authenticates at your place before you get the time to do it yourself. If you think that it is too hard to watch all forums accounts for a new posted secret and authenticate before the player, note that there is a RSS feed which gives in real time all profiles changes. How to prevent the attack ? Make sure to bind the token to the third party account. This way, if someone else tries to authenticate with the token, the local account won't match. As a good practice, also send the token in private and not in a public channel. 3) Weak or lack of verification Some applications may forget to actually verify the token (don't laugh, a bug is always possible). So make sure to test it after each code update. Another important point: the forums user feed also contains data from the posts liked or messages posted. If the verification function just looks for the token anywhere in the page, a hacker could create a post with his token in the title and this secret will appear in the feed of whoever likes or answers it. So make sure to only check in profile updates. 4) Validating the wrong profile If the player enters the URL of his profile (on the forum, this is nearly mandatory as there is no easy way to know the profile URL based only on the player name), it is possible to host a webpage on another website with a copy of your profile with modified information about your pledge, title or organizations. Thus, it is important to double-check when validating the token and gathering player information that the URL domain is actually correct! Hint: it should be something like *.dualthegame.com (make sure to test against URLs like "*.dualthegame.com.hacker.com" or "hacker.com/*.dualthegame.com"). 5) Luring someone else to edit his/her own profile This one is a bit tricky. Let me break it down into a detailed scenario: I start authenticating on Achilles' Discord which requests me to put the "123456" token in my forums profile. I don't do it right now and instead setup my own application with authentication. I share my application with Hector who tries to authenticate there. He is requested to put the same "123456" token on his profile. Hector put the token on his profile (and finishes authentication on my application for what matters). I finalize authentication on Achilles' Discord indicating that I'm "Hector". And now, Achilles' Discord thinks that I'm Hector. Tricky. A quick and easy recommendation is to generate a token which is clearly related to your application. So, for example, Achilles' Discord could have generated a token like `Code for authenticating with Achilles' Discord (don't use this code if it was not given to you by the "Achilles' Bot"): 123456`. As Hector is a smart guy, he would probably not put this token for authenticating with an application which is not named "Achilles' Discord". It is not perfect as a player who is not paying attention can blindly copy/paste the code. 6) Quits and bans Last but not least: players may quit an organization, be kicked from ATV or lose their backer title for whatever reasons. Thus, if a third party application records groups and roles only once during authentication, the player rights may become outdated in the future. It is important to regularly check the player organisations, titles and rights and update them accordingly (ideally before any request, but realistically a check every hour or day is ok-ish). I hope this post will help. Feel free to ask questions or repost it anywhere. Regards, Shadow