3. Auth Tokens

Auth Tokens


  • Sharing a password is a bad idea. If i decide to stop using a 3rd party I can just disable the token I created for them. I can also limit the scope of a token. I don't need to trust my 3rd party tool with the ability TO CHANGE MY PASSWORD, when I only want it to read memory segment 1 for stats collection.

    1 Reply
  • Culture

    @deft-code again, there is no "sharing" of a password. I'm not sure why people are misunderstanding this so badly, but let me try to explain this again using the Github security model.

    Look at Gitconsensus. It works with Github and follows all of the guidelines Github makes. Anyone who wants to use Gitconsensus can download it themselves, run the gitconsensus auth command (which will ask for their username, password, and if needed their 2FA token), and then they will have a token saved to their system that Gitconsensus will use every time after that rather than using a username and password combination.

    At no point does anyone share a password with me. There is no sharing credentials with a third party. There are hundreds of apps that work with Github in the same way, and this is the prefered method of authentication for people using Github with tools that they are running on their own computers.

    Now apply this to the "interactive console". The way it works, and will continue to work, with private servers is that people enter their username and password to authenticate. That isn't going away, as the token system is not (as far as I know) being applied to private servers. So every user who is using a private server will have to share credentials to use a third party tool (that they are hosting themselves). If someone wanted to connect to the public server my proposal would allow them to log in the same way (if they wanted), but instead of storing their credentials on their system like it would with the private servers it would swap the credentials for a token that is specific to that install of that app.

    At no point would the console have the ability to do anything else. The "recaptcha" portion means there is no automated login without the user interacting. There is no ability to "change your password".

    Now I can already see people gearing up to ask the question- what if the application is malware and tries to steal the credentials? Well, if that's the case, you just installed malware on your computer and chances are it's going to do a hell of a lot more than steal your "screeps" password. If you are legit worried about screeps third party tools being undetected malware then you don't just have your credentials to worry about, you need to worry about every file on your computer. At that point, if I am a malware author, I'm going to cryptolocker you and ask for bitcoins to unlock your files, while also shoving a keylogger in the background and maybe a rogue chrome extension- I am not going to try to screw with your video game.

    1 Reply
  • Dev Team

    @tedivm We already have POST /api/user/auth-token to generate tokens (which is used by the Auth Tokens UI). So what you propose is to allow Basic Authentication on this endpoint, like on /api/user/code, right?

    1 Reply
  • Culture

    @artch yup.

    1 Reply
  • Dev Team

    @tedivm OK this seems viable. Done.

    👍
  • Dev Team

    As announced before, the /api/auth/signin endpoint now uses Google Invisible reCAPTCHA. If you haven't changed your auth flow to tokens yet, please do this ASAP.


  • This post is deleted!