API keys are not a viable proof of identity
MentalFS.2589:
With the introduction of OAuth, many places like TS3 servers or forums used it for authentication, especially WvW-based ones. It was all fine and good until OAuth got replaced for security reasons. Lots of those places did what seems the right thing: Replacing the OAuth flow with prompting the user to enter an API key.
The thing is: While you had to register your OAuth app and tokens where only usable by that app, API keys are reusable. As the API is expanded, a lot of more or less useful apps are seeing the day of light. Users enter their API keys. And those keys can be used everywhere.
So imagine you want to spy on rival WvW world’s forums. You create an app, let’s say one that creates a banner for forum signatures. People use it, enter API keys and voilà – tons of reusable API keys from all servers are in your database. You can go sniffing in those forums and even post under a false name.
I’m just leaving this here as a starting point for a discussion, but to me this means that an API key is no proof that the account assiociated with it is actually the user’s account and should not be used as such, especially if it could lead to blocking or even reporting an account based on actions on that platform.
smiley.1438:
This was also my concern mentioned in this thread: https://forum-en.guildwars2.com/forum/community/api/HEADS-UP-OAuth2-being-replaced-next-week
€:
See also this thread: https://forum-en.guildwars2.com/forum/community/api/Web-registration-using-keys
MentalFS.2589:
Thanks, I remembered someone mentioning it but it didn’t get the attention that it deserved.
Lawton Campbell.8517:
You’re totally right — API keys aren’t usable for authentication. There’s really no way around that, since API keys provide symmetric authorization.
The strategy I’ve recommended to others is a kludge, but the most viable I can come up with: when you get an API key, resolve the account name and world via /v2/account, then bind the account name to the TS3 identity. If the account name has already been used, have the automated system fall back to the usual manual verification step (and de-authorize the account that was using that name). You can add in special process for having multiple TS3 identities with a single GW2 account (presumably people who need multiple idents will be few and well known within the community).
This prevents, at least, sharing API keys as it basically maps each GW2 account to a TS3 identity 1:1.
Slyfer.6478:
Yup, this issue is a pain. Needless to say if you have a guild forum, this type of security hole will be an even bigger pain. Was thinking of temporarily banning the valid user if someone uses their key and resort to moderators to sort it out. If it turns out the first key user is a fraud, ask the valid registering user to delete key > make new key > register again. If it’s the other way around though… should i get the user to manually make a new key or make them exempt from future temporary bans?
EDIT: On another note i’d like to see statistical proof of some sor (if anyone has researched this more in-depth please link me to an article, i’m unable to find any that provide statistical proof) that API keys are more secure, as i see it both have exactly the same security hole just OAuth is more convenient and can actually be used for authenticating. People aware of phishing already check the address and people unaware can still be victims of phishing by redirecting them to a make-shift ‘login to generate key’ page for sake of convenience. How many really write down their api-key or use an auto-filler? Any time i use mine i login to account page to copy-paste anyway (and if the third-party provides a redirect to gw2 login i’d take it instead of typing the valid address myself) but i have no idea if i’m in the minority or majority.
Risingashes.8694:
Couldn’t you just require two API keys in order to verify?
That’d mean the spoofer would need to get multiple different keys from a single source in order to fake an identity.
This doesn’t seem possible unless the person created multiple apps and somehow convinced users to provide different keys, which seems unlikely.
Once more options for keys are revealed, you could demand keys that require access to very specific areas only (such as account and something innocuous and unrelated like armor dyes and talent selections), this would almost guarantee that users created new keys for this specific purpose as malicious key requesters would find it hard to justify requiring those specific unrelated permissions and those only.
smiley.1438:
I’m less concerned about the verification of an API key since this PR (https://github.com/arenanet/api-cdi/pull/27) might be a solution, i’m more concerned about the fact that authorization (log in with gw2) is impossible.
Imagine a GW related website which would attract a huge amount of users. Each user provides an email address and a password along with some other personal information. A hacker finds an exploit and gets his hands on the user database via some SQL injection on the poorly programmed backend and is able to decrypt the md5-hashed passwords in no time (thanks to rainbow tables). He tries to log-in on the GW account website with each of those credentials with a huge success rate due to ignorant users who use the same credentials all over the web.
THIS HAPPENED FOR REAL IN THE PAST!
If the whole thing would have run with an OAuth log-in, noone would have been harmed (except for maybe a few PEBCAK who fell prey to the natural selection. sorry.). The OAuth tokens don’t let you access the account itself – just the API.
Lawton Campbell.8517:
Couldn’t you just require two API keys in order to verify?
That’d mean the spoofer would need to get multiple different keys from a single source in order to fake an identity.
That doesn’t work. If requiring two keys becomes the norm, then the spoofer will have two keys for each of their users.
I’m less concerned about the verification of an API key since this PR (https://github.com/arenanet/api-cdi/pull/27) might be a solution, i’m more concerned about the fact that authorization (log in with gw2) is impossible.
I’m not clear on how that’s a solution for verification. Would the application only accept keys that have a specific name?
smiley.1438:
I’m less concerned about the verification of an API key since this PR (https://github.com/arenanet/api-cdi/pull/27) might be a solution, i’m more concerned about the fact that authorization (log in with gw2) is impossible.
I’m not clear on how that’s a solution for verification. Would the application only accept keys that have a specific name?
Exactly. You would check the API key against /v2/tokeninfo an look for a keyname like “my awesome website SOME_RANDOM_HASH” which you provided to the user while he was about to register with your website.
lynnae.4095:
i’m more concerned about the fact that authorization (log in with gw2) is impossible.
Authentication is not possible right now. Delegated authorization is.
I think what you’re looking for is OpenIdConnect, which uses JWT tokens to build authentication using the OAuth specifications.
Bugabuga.9721:
Basically, in order for API keys to be somewhat useful for authentication, they should:
- contain verifiable time of creation
- allow “customization” of the token with destination/application field.
This would allow applications to be a bit more certain about the owner of the keys.
When user is asked for API Key, time of “ask” gets recorded, and keys earlier than that timestamp would be rejected. Same with destination field.
The reason for app name / destination versus “Name” user gives the token is that user might provide something sensitive there under impression that name is private. So “Application” could be useful.
API Key creation time probably can be exposed as-is
https://github.com/arenanet/api-cdi/pull/27#issuecomment-109486617
Risingashes.8694:
I actually just realized that we’re all missing a fairly foolproof and non-fiddly method of ensuring a key is not a stolen one.
All we’d need is a /v2/apikey endpoint (something I’m sure had been proposed and approved but for some reason I can’t find the thread) that exposed the chosen name of the key and then our apps/sites would only recognize keys with a specific and unmistakable name. Eg. BlackRockWvW would require keys with the name “This key should only be used for BlackRockWvW.com” (with certain required permissions as appropriate).
Any other site trying to get someone to make a key with that name would be obvious to even the most unattentive of users. Malicious users with second accounts would have to be thought about, but this is a problem outside the scope of this discussion.
Edit: “I’m not clear on how that’s a solution for verification. Would the application only accept keys that have a specific name?”
Because I only read the reply to my specific post I completely missed that this was already brought up by @Lawton. But since they phrased it in the form of a question I’m still claiming credit
That doesn’t work. If requiring two keys becomes the norm, then the spoofer will have two keys for each of their users.
The above being said, which makes what I’m about to say redundant, I still think what you’ve said misses the point.
It would result in two keys becoming the norm for apps using keys for the purpose of identification.
Let’s say the spoofer ran GW2TheBestTP.com. Them asking for two keys would be suspicious as there would be no need to require ensuring identity, only to draw information. Obviously end-users may not view this as suspicious, or it’d be fairly straight forward for a site to trick a user in to providing two keys via a simulated error message about the original key being ‘damaged’.
So in that case you’d refer to the second part of my post and require specific permissions. Once authorized endpoints are complete we’re likely to have a fair few options. So if BlackrockWvW.com required two API keys with \WvW\, \Character\, \Traits\, \WvWTraits\, \Achievements\, \GraphicalSettings\ and those categories only exposed then a malicious GW2TheBestTP.com requiring an two API keys with all these endpoints and only these endpoints would be automatically suspicious because endusers are not even exposing data relevant to the site.
This would mean spoofer sites would need to develop concept functionality which is relevant to the categories chosen by BlackrockWvW.com.
So I don’t think it’s as simple as “two keys would become the norm”. Each additional requirement would dramatically increase the suspicion levels of users when dealing with malicious sites.
That being said, my above solution (exposing names of keys and having sites choose unique names) would be far less taxing on users and most intuitive.
AllIsVain.6409:
For local applications you can tie in to the Mumble Link API and validate the account name – API key that way as an extra step (Overwolf applications included in that). Not the best way of doing it but it works.
MentalFS.2589:
Exposing the name was brought up in the github pull request linked by smiley, so the credit goes there.
I do think this would make an easy and pretty safe solution to request, for example, your domain name to be part of the API key name. Still not very user friendly though, but that ship sailed with the introduction of API keys altogether.
I think there was an additional field beyond name that was removed to reduce clutter. The creation date could be useful too, if you really want to ensure that it’s a fresh key.
Slyfer.6478:
That being said, my above solution (exposing names of keys and having sites choose unique names) would be far less taxing on users and most intuitive.
This. It is still a hack on top of a hack for a still persistent security issue but this is something that i could work with.
MentalFS.2589:
This. It is still a hack on top of a hack for a still persistent security issue but this is something that i could work with.
Yo dawg, I heard you like hacks…
Edit: tokeninfo is now active, with name and permissions.