Api: Drop API key completely maybe?

[gelraen]

http://destinydevs.github.io/BungieNetPlatform/docs/Getting-Started has examples of using API key on browser side. DIM and braytech.org do exactly that. Their API keys are 5ec01caf6aee450d9dabe646294ffdc9 and 9f8a83dc91b145e8be66b6daba729ea8 respectively.

I can imagine 2 scenarios for this to happen:
1) DIM and braytech.org are horribly broken and must be urgently fixed
2) API keys are redundant and don't serve any purpose anyway

Given that the world is not burning down, I think it's the second option :) In which case, it's probably better to remove API keys completely, so that they don't give anyone involved a false sense of security.

[BinarMorker]

Keys allow filtering by domain, so I guess this is no big deal if the key
is exposed: it can't be used by another app anyway.

On Sun, Aug 4, 2019, 6:20 PM Maxim Ignatenko [e-mail]
wrote:

http://destinydevs.github.io/BungieNetPlatform/docs/Getting-Started has
examples of using API key on browser side. DIM and braytech.org do
exactly that. Their API keys are 5ec01caf6aee450d9dabe646294ffdc9 and
9f8a83dc91b145e8be66b6daba729ea8 respectively.

I can imagine 2 scenarios for this to happen:

1. DIM and braytech.org are horribly broken and must be urgently fixed
2. API keys are redundant and don't serve any purpose anyway

Given that the world is not burning down, I think it's the second option
:) In which case, it's probably better to remove API keys completely, so
that they don't give anyone involved a false sense of security.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Bungie-net/api/issues/998?email_source=notifications&email_token=ABMHLKUOQOH7RZNAJ23VCQLQC5I4TA5CNFSM4IJGLVTKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HDILACA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABMHLKXPTT7PFZRXLJNAWFDQC5I4TANCNFSM4IJGLVTA
.

[floatingatoll]

A year or so ago Bungie indicated that API keys aren’t meant to be particularly secret and that they wanted to ensure that individual API keys never become “hot property” such that anyone has incentive to steal them.

You can self-issue an API key identical to those used by DIM at any time through the Bungie.net website, but rate-limiting is afaik implemented per IP, not per API key, doubling down on the whole “no point in stealing them” thing.

On Aug 4, 2019, at 15:35, François Allard [e-mail] wrote:

Keys allow filtering by domain, so I guess this is no big deal if the key
is exposed: it can't be used by another app anyway.

On Sun, Aug 4, 2019, 6:20 PM Maxim Ignatenko [e-mail]
wrote:

http://destinydevs.github.io/BungieNetPlatform/docs/Getting-Started has
examples of using API key on browser side. DIM and braytech.org do
exactly that. Their API keys are 5ec01caf6aee450d9dabe646294ffdc9 and
9f8a83dc91b145e8be66b6daba729ea8 respectively.

I can imagine 2 scenarios for this to happen:

1. DIM and braytech.org are horribly broken and must be urgently fixed
2. API keys are redundant and don't serve any purpose anyway

Given that the world is not burning down, I think it's the second option
:) In which case, it's probably better to remove API keys completely, so
that they don't give anyone involved a false sense of security.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Bungie-net/api/issues/998?email_source=notifications&email_token=ABMHLKUOQOH7RZNAJ23VCQLQC5I4TA5CNFSM4IJGLVTKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HDILACA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABMHLKXPTT7PFZRXLJNAWFDQC5I4TANCNFSM4IJGLVTA
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[gelraen]

Since there's "no point in stealing" them, there's probably no point in having them at all. Which is my point exactly.

[floatingatoll]

Having them and requiring people issue them is extremely valuable, operationally.

If someone’s app has a bug that causes a refresh every second, the app’s author can be trivially identified and contacted through Bungie.net or any other available method.

As an Internet Ops person, I would never give up API keys for a public API, even if they’re issued freely, for that single reason alone.

On Aug 4, 2019, at 15:45, Maxim Ignatenko [e-mail] wrote:

Since there's "no point in stealing" them, there's probably no point in having them at all. Which is my point exactly.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[vthornheart-bng]

Floatingatoll covers the reasons why we have an API key pretty well. It's not intended as a security mechanism, but rather as a path for self identification in well behaved and well intentioned apps. We require its use as a matter of policy.

[Yogarine]

I feel this is not the whole answer.

There are two types of uses for API keys. Client-side (public) and server-side (confidential).
(I know, “public” and “confidential” actually describe the different Oauth methods, but I think the same terminology applies here)

Public use of an API key (like DIM and Braytech) need you to set an Origin Header in the Application configuration at Bungie.net to prevent abuse.

Confidential usage from a server (such as I am currently building and I presume Ishtar does this as well) doesn’t really allow for an Origin Header so in that case it’s important the API key is kept secret to prevent abuse. However even in this case if the API key leaks, there is no security risk since an Oath token is still required to actually perform operations on the behalf of a Bungie.net user.

I’d also like to note that the Origin header for public API keys does naively assume that a browser is used. I believe it’s quite easy to spoof the Origin header by writing a little proxy.

[floatingatoll]

Ishtar is in-client only.

Keys without an origin set are expected to be used in clients that aren’t a web page.

There is no abuse possible of any API key, as one can simply self-issue an API key.

Bungie.net does not use API keys to prevent abuse. It uses them only as a “who wrote this code” soft identifier. I’m not sure any API key has ever been blocked ever in the three years they’ve been running this system. (Haven’t asked, not seen GitHub issues about it, so caveat emptor and so forth.)

A server is expected to keep client authorization tokens and refresh tokens confidential, but the API key is purely a public identifier and is both known to be and designed to be public.

Any definitions of keys, tokens, confidentiality that may be present in other specs (like the OAuth spec) will need to be consider advisory only here.

On Aug 5, 2019, at 11:26, Alwin Garside [e-mail] wrote:

I feel this is not the whole answer.

There are two types of uses for API keys. Client-side (public) and server-side (confidential).
(I know, “public” and “confidential” actually describe the different Oauth methods, but I think the same terminology applies here)

Public use of an API key (like DIM and Braytech) need you to set an Origin Header in the Application configuration at Bungie.net to prevent abuse.

Confidential usage from a server (such as I am currently building and I presume Ishtar does this as well) doesn’t really allow for an Origin Header so in that case it’s important the API key is kept secret to prevent abuse. However even in this case if the API key leaks, there is no security risk since an Oath token is still required to actually perform operations on the behalf of a Bungie.net user.

I’d also like to note that the Origin header for public API keys does naively assume that a browser is used. I believe it’s quite easy to spoof the Origin header by writing a little proxy.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[zhirsch]

Would it be possible to spoof a different client, e.g. take DIM's API key and with the help of a proxy server change the Origin header to match what Bungie.net expects? Then this spoofed client could abuse the system and cause headaches for Bungie, DIM, and their users?

If the main goal is to identify the owner of the code that is calling Bungie.net, then maybe a sufficiently malicious person could cloud those waters. The mitigation would be to issue a new API key, but then it's a race to see whether the API keys can be issued faster than they can be stolen (and in the meantime, it's a poor experience for e.g. DIM's users).

[Yogarine]

@floatingatoll
I assume Ishtar has scripts to download the manifests and stuff server-side, I was thinking about that. But I guess that might just as well use the same API key as their client-side portion.

Also I guess "abuse" is the wrong word. I just meant "inappropriate use".

@zhirsch
Like floatingatoll mentioned, there isn't much you can do with just an API key. You still need an Oauth token to actually do something that can impact users. Oauth authentication requires redirecting to the domain registered with the API key.

[floatingatoll]

Yes, it would be possible to take down the Bungie API using any api key.

This would of course result in a new api key being issued and a client point release that rotates to the new key.

Since there’s no “quota per api key”, if the api goes down, your private server’s api key will stop working right along with all other api keys. We’re all in the same boat here.

Zero attacks of this nature have occurred to date, and Bungie considers the API “optional” and has taken it down for days at a time for internal reasons at various points in time. Do not expect high availability service from the API (and remember to adhere to the “we may not require money in exchange for tools that use the Bungie API” guideline).

On Aug 5, 2019, at 12:02, Zachary Hirsch [e-mail] wrote:

Would it be possible to spoof a different client, e.g. take DIM's API key and with the help of a proxy server change the Origin header to match what Bungie.net expects? Then this spoofed client could abuse the system and cause headaches for Bungie, DIM, and their users?

If the main goal is to identify the owner of the code that is calling Bungie.net, then maybe a sufficiently malicious person could cloud those waters. The mitigation would be to issue a new API key, but then it's a race to see whether the API keys can be issued faster than they can be stolen (and in the meantime, it's a poor experience for e.g. DIM's users).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[vthornheart-bng]

I should note that there is technically a throttle per API Key, but we are currently very lenient on it - just as we are lenient on people creating multiple applications with multiple API Keys if they desired. The API Key is a mechanism that helps honest people stay honest and keep in communication with us about their activity - and in turn, allows us to inform them more easily about situations such as hitting the limits of allowed usage. It alone is not meant to be a system that protects against malicious agents. We have other safeguards in place for those contingencies.

[gelraen]

Apologies for a late response.

Okay, so since we all here agree that API key is not meant to securely authenticate an application, but simply identify it, maybe stop calling it a "key"? "App ID" would work just as well. Word "key" in this context has certain connotations that usually mean that the "key" needs to be kept secret from third parties.

I know that this looks like a lot more work than it's worth (and it probably is), so maybe at least add a note in the UI on https://www.bungie.net/en/Application somewhere, stating that it's more of an ID rather than a key?

Other than this, my main beef with API key is that it stands in a way of just editing URL in the browser for poking things manually for what feels like no good reason.

[floatingatoll]

If you use a browser addon that lets you add arbitrary headers to requests matching a certain URL (as Chrome and Firefox offer), you may find that useful for local development purposes.

On Sep 16, 2019, at 14:51, Maxim Ignatenko [e-mail] wrote:


Apologies for a late response.

Okay, so since we all here agree that API key is not meant to securely authenticate an application, but simply identify it, maybe stop calling it a "key"? "App ID" would work just as well. Word "key" in this context has certain connotations that usually mean that the "key" needs to be kept secret from third parties.

I know that this looks like a lot more work than it's worth (and it probably is), so maybe at least add a note in the UI on https://www.bungie.net/en/Application somewhere, stating that it's more of an ID rather than a key?

Other than this, my main beef with API key is that it stands in a way of just editing URL in the browser for poking things manually for what feels like no good reason.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[gelraen]

Extension permission systems in both of those browser aren't adequate enough for me to have such extension permanently enabled with an easy mind. And if I'm going to hassle with enabling it manually every time I need it - firing up a terminal, where I have curl | jq, seems like a better alternative :man_shrugging:

[floatingatoll]

“resty” is very effective for Bungie API as well.

On Sep 16, 2019, at 15:08, Maxim Ignatenko [e-mail] wrote:


Extension permission systems in both of those browser aren't adequate enough for me to have such extension permanently enabled with an easy mind. And if I'm going to hassle with enabling it manually every time I need it - firing up a terminal, where I have curl | jq, seems like a better alternative 🤷‍♂

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[andyschott]

Have you ever used Postman? You'll need to do the OAuth dance once to get a token, but after that you should be able to add the token to your headers and then query the API with Postman. It also lets you save URLs for later, so it would be fairly straightforward to query the same URLs repeatedly if you want to.

[gelraen]

FYI, I did not ask for software/workflow advice in any of my messages here, thank you very much.

[floatingatoll]

This issue, in summary, is “API keys inconvenience me, please remove or rename them”. Bungie declined to do so. In light of that denial, we’re trying to offer ways you can alter your workflow to accommodate the inconvenience - and also leave a paper trail for future visitors to this thread, who are trying to solve the same issues as you are. While it may seem the advice is personal, it is in practice directed at others as much as you.

My mail client — Unibox — doesn’t show me who GitHub messages are from^, so I’m likely to repeat my offense of being unasked-supportive towards commenters and future visitors in future issues. I apologize in advance for any present and future unhappiness this approach causes you, and I wish you luck in your future efforts to resolve other inconveniences.

^ I’m not looking for advice on other mail clients at this time; Unibox meets my workflow needs and I consider this particular deficiency acceptable given the circumstances.

On Sep 16, 2019, at 16:30, Maxim Ignatenko [e-mail] wrote:


FYI, I did not ask for software/workflow advice in any of my messages here, thank you very much.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Yogarine]

Other than this, my main beef with API key is that it stands in a way of just editing URL in the browser for poking things manually for what feels like no good reason.

I just wanted to add here that web browsers aren't supposed to be API clients, nor are APIs supposed to be designed to facilitate easy web browsing. As such web browser access to the API should have zero influence in how the API is designed, and even a "no good reason" beats accommodating to web browser compatibility.

[justrealmilk]

Alexa, turn off notifications