3. Auth Tokens

Auth Tokens

  • Culture

    @jbyoshi most (not all, but most) of the third party tools aren't compiled so you don't have to worry about binary matching. This same problem exists for a variety of tools- mail clients being a popular one- and with the "full access" token granting "full access" there isn't much difference between a token and a set of credentials when it comes to access.

  • Dev Team

    The difference is that a token can be revoked at any moment.

    1 Reply
  • Culture

    @artch a password can also be changed at any moment, and since the method I proposed still relies on a token for all major operations those tokens can also be revoked right after the password is.

    I don't mean to get into an argument, and if this idea isn't a priority then that doesn't bother me all that much. From a security standpoint though this isn't as big of a deal as people are making it out to be.

    1 Reply
  • YP

    Well I did not try but I think full access tokens should not let you change your email, password, cancel the account or link it to a steam account, open support tickets and other account stuff like that.

    Also I think it's important to teach people to not enter credentials of whatever account to 3rd party sites.

    1 Reply
  • Culture

    @w4rl0ck for the record, Github themselves use the exact method I'm proposing for their API. Here's the relevant code on Gitconsensus. As much as I love Screeps I tend to consider Github to have much higher security requirements and they have no problem with this method.

    Encouraging people not to enter their credentials into third party sites is super important, which is why I included it in the third party tools page right at the top. Another thing we should do is encourage them not to use the same password in multiple places, as that can result in it getting out and causing more issues. I totally agree with this.

    However, if we're already encouraging people to open up a webview in their application for authentication (something that has come up in this thread repeatedly, and which would easily allow someone to screenshot or keylog credentials) there isn't much of a difference between that and an official way to get a token. This just adds a layer of convenience, especially for people who want to put one of these tokens on a mobile client.

    2 Replies
  • Dev Team

    @tedivm said in Auth Tokens:

    However, if we're already encouraging people to open up a webview in their application for authentication (something that has come up in this thread repeatedly, and which would easily allow someone to screenshot or keylog credentials) there isn't much of a difference between that and an official way to get a token.

    Just for the record - the https://screeps.com/a/#!/account/auth-tokens/noratelimit?token=XXX embeddable UI doesn't require authentication, it can be used by an anonymous visitor, there is no login popup. Its purpose is to solve CAPTCHA rather than to authenticate the user.

    ❤
  • YP

    @tedivm for the record, I would never courage someone to enter his github credentials at any other site, nor do I think github states anywhere that you should do so. If I would enter my github credentials at other sites I would have serious problems at work.

    They might have the api for personal tools, but for sure not to enter credentials at different sites. They have a page where they tell their user to never share their passwords with anyone: https://help.github.com/articles/creating-a-strong-password/

    @artch : I see a possible problem with the turning off rate limiting for 2 hours for specific tokens. Maybe those tokens should be changed that they can only used when enabled with the link.

    The problem I see is that a 3rd party client could use up all daily usages of a endpoint, for example the memory access, while the limits are not disabled, so other scripts would no longer work at all for the day. Or does pressing the button also resets the api limits?

    1 Reply
  • Culture

    @W4rl0ck exactly. Github tells people not to enter their credentials into third party sites- just like we already do with screeps credentials on the third party page I wrote- but they allow the option for applications people are hosting on their own. If you download Github's own desktop client it doesn't ask you for an authentication token, it asks you for a username and password. If that's good enough for github I think it's good enough for screeps.


  • 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!