Private only API key

    • Usability

    • Private only API key

      I wanted to use the new API for a userscript (something similar to SpioHelper) and so I asked in the IRC about the API key you need to access the API. I was told that using that key in a userscript would obviously make the key public and that would be easily abusable.

      So I thought: Why not add a private use only API key? That means everyone would have an own key and they could provide it to the script so it can access the own information on the API only. Another possibility: Give access to the own API with user data, i.e. username and password.

      What do you guys think?
    • I have thinked about this too.

      Today API key is usable only by websites. All tools based on Javascript cannot use API because the API key will be shared to everybody. (The problem is that currently most of extensions are based on JS scripts)

      There are two options:
      - For each tool the developper will create a webservice on his own server and with his own API key.

      - And the second option will be to have an API key by player. Like this the player enters his API Key in a tool and will be able to communicate directly with the Ogame Server.

      OGSteam is a team that develops and tests Legal Tools for OGame.
      forum.ogsteam.fr
      Please help us to translate OGSteam Tools : transifex.com/ogsteam
    • Creating an API key by player is worst than leaving the API reachable without API Key, because it means that you can reach the API with a false identity.

      And honestly, what's the chance for having abuses of the API ? The current API link seems to be a string of 40 hexa characters, so the chance to get a report by hazard is 16^40, and you have to find it before that the report is deleted I suppose.

      The chance to abuse the API and get the report YOU WANT is inexisting.

      Are you sure this API Key is needed ?
    • By hazard yes. But if you write a program which goes through every possible combination of IDs continously and filters them by the player(s) you're looking for, that would be very exploitable.

      I don't know how the supervision is of the tools that are allowed to use the API, but I kind of find it questionable how it is handled right now. But there should be a possibility that the player can retrieve own information from the API. Since userscripts are open source, there is no chance that can be abused.

      Why should a "private only API key" be worse than no API key at all? It's like a password that you should keep secret from others. As long as you don't give it to anyone, noone will be able to access your information via API.
    • By hazard yes. But if you write a program which goes through every
      possible combination of IDs continously and filters them by the
      player(s) you're looking for, that would be very exploitable.
      You are serious ? Do you know the time and the ressource needed to test 16^40 combinations ? If you really think that there is a security matter with this implementation, you have exactly the same issue with the API Key; the JSON answers "4001" if the API Key is wrong, so you " write a program which goes through every possible combination of API Key continously " till the server answers other thing than 4001.

      And remember in this case that to "abuse" as you say, you have to find a combat report before than the fleet is back to the planet... If not OK you grab a report you logically dont have right but... WTF can you make with it ?

      Support.ogame.fr uses strings only to auth since many years.

      If you don't take in consideration the standalone security of a 40hexa string, we can say too that the tools having an API Key can be used themselves to bruteforce the API (" writing a program which give all combination to the tool and see if the tool answers ") ? We should be serious.
      Why should a "private only API key" be worse than no API key at all?
      It's like a password that you should keep secret from others. As long as
      you don't give it to anyone, noone will be able to access your
      information via API.
      For two reasons :

      First of all, it means that you give the responsability of a part of security to the final client, and its NEVER a good idea.

      Secundly, the accounts can be given to another players, so an old owner of an account can know the private API Key, and can make bruteforce attempt on API ONLY to set the account in trouble if there is a security handling on bruteforce attacks on the API.

      anyone willing to create something using it is limited to buying a server. Not everyone is willing to shell out that money.
      There is another way : asking to an existing tool having an API Key to returns JSON direct answer for usersscripts. Userscripts at this moment will just have to send the ID to their resources, the API Key used is the one of the remote tool, and userscript receives the answer.
    • First of all, the bruteforce matter is simply solved by disabling the API key if more than 100/1000 attempts are made with wrong codes.

      iguypouf wrote:

      First of all, it means that you give the responsability of a part of security to the final client, and its NEVER a good idea.


      We already have scripts read every last detail on each page and send it to a remote server, with no way of knowing if the user is the only one reading that data. Letting scripts use API keys, that need to be first harvested by visiting the page they show up on, is no different than reading the entire report in v5.

      iguypouf wrote:

      Secundly, the accounts can be given to another players, so an old owner of an account can know the private API Key, and can make bruteforce attempt on API ONLY to set the account in trouble if there is a security handling on bruteforce attacks on the API.


      Accounts that are given/traded need to be reported to the GOs, otherwise they get banned/it's not a legit acc transfer. While it should be the users responsibility to refresh the API key (along with changing the password), the GOs could force an update to the API key and just solve the problem this way.

      iguypouf wrote:

      There is another way : asking to an existing tool having an API Key to returns JSON direct answer for usersscripts. Userscripts at this moment will just have to send the ID to their resources, the API Key used is the one of the remote tool, and userscript receives the answer.


      Depends on scripts having remote servers (which cost money). If the script communicates with a tool, the tool needs to be compatible with the said script, which is probably more work than what some may be willing to do. Also moves the exploit target from GF servers to the tool, which isn't really that much difference IMO.


      What I'd suggest, is that the current API keys are kept, giving tools the ability to harvest any report from any server/player, so users can use them. But, in addition, create user-specific API keys that only allows them access to their own reports. That way scripts can seriously do message filtering again, without which you can bet many people will quit.