From EVEDev
Jump to: navigation, search



  • There is currently no way to securely verify someone's identity
  • It is not very convenient for the user to copy and paste his API key into every application/website
  • Because a single API key per user is used for every application/website, the user has think twice who to trust his API key
  • [insert more here]

Existing Solutions/Workarounds

In-Game Browser (IGB)

  • The headers can easily be spoofed

Transfer to my alt 0.XX ISK to prove you're you


You can set up an alt on your account to use for verification purposes.
Simply create this alt, and have your site call the API and get wallet
information. For verification, have the character send some small amount
of ISK, .01 to 1000.00 or so, to the alt, and you can verify the account
on the next API grab. It might be easier if CCP was to add something in,
but this will work for the mean time.

Mantalari Altis:

Technically, this will work, but it is an enormous kludge. For starters,
you can only download the wallet once per hour, so the user's going to
potentially be waiting a long time before the account can be verified.
Then there's the fact that the alt needs to pretty much be dedicated to
the purpose because you can't have any other reason that the person may
have sent the alt the isk... finally, it is still prone to forgery because
the forger can simply concoct a reason for the real character to send the
account the right amount of isk (Here's the module you wanted. I got it
from a friend. But you could pay him for it. Send him 1000 isk please.
Or maybe... Hey, I'm playing a joke on my buddy by getting everyone i
can think of to send him 0.01 isk)


The ISK method was merely created as an example work-around for the current
problem at hand. It was never intended to be a foolproof method, but merely
a hypothetical idea put down in raw code to be examined and tested by others.

Obviously it has it flaws, most specifically having the API exhaust if you
recieve too many activations in one time, but it does indeed provide a method
for identifying the user giving your application the API key.

API key

<Garthagk> [The API key is] not designed for authentication. You're
           certainly welcome to use it that way if you wish, but all
           you're proving is that -someone- posesses the API key and userid.

<Garthagk> You're not proving who the person on the other end of the line
           is in any way.
  • Not designed for authentication
  • Evil site may use API key to do evil things on 3rd party website

Forum token

<Dal_Rath> posting a supplied token in the test forum and having the 3rd party
           site spider the forum page would also work but it's a kludge
<MD87>     I think kludge would be an understatement :D

Proposed Solutions


To plainly verify someone's identity Kirsten Fud suggested OpenID

<Garthagk> yeah, we'd basically define a URL, something like...
<Garthagk> so, user gives userid+apikey to remote site, site does
           the redirects as above, and using openid can prove that
           this user has the login/password to that userid
<Garthagk> and then it can do its own apikey verification
<Garthagk> I'm still not sold on what it buys people.. if they're
           giving out their apikey they're probably giving out their
           password :p
<Garthagk> the only thing it stops is someone writing some website
           and harvesting apikeys and using that information against
           other people's sites/tools
<Garthagk> guess it's useful for things like forums
<iteron>   is the api key really required in the process?
<Garthagk> no
<Garthagk> I don't want people giving out their usernames, so they'd
           have to give out something, userid works I guess
<iteron>   the OpenID python example supports two modes:
<iteron>   either the user enters the full url like
           including his user id
<Garthagk> nah, sites wouldn't use URLs to the user
<Garthagk> they'd have the user enter their userid, and internally
           they would create the URL out of it
<iteron>   or he leaves the userid empty
           ( and is prompted to
           enter his credentials
<Garthagk> I'm relatively certain you have to give something to the
           requesting site
<Garthagk> as it's part of the signing process
<Garthagk> been a while since I looked at the code tho
<MD87>     I don't think so
<iteron>   only the url to return to
<Garthagk> ah hm
<MD87>     So you could click a "Log in" button on a fansite, get 
           redirected to myeve, log in with your usename/password
           (hmm, phishing potential++?), and then get redirected back
           to the fan site with the relevant details in the query
<iteron>   the python example also demonstrates retrieving registration
           data, eg. the user's full name
<MD87>     and then behind the scenes the fan site sends a request to
           myeve to get some details, or something... it's been a while
           since I read the spec
<Garthagk> ah right
<Garthagk> okay
<Garthagk> large phishing potential that would have to be addressed.


<MD87>     Garthagk: What about making a third type of key that's single
           use, and only allows access to a script to check it's valid?
<Garthagk> [...] it doesn't really prevent phishing
<Garthagk> Most users are going to end up at site X that they want access
           to, site X is going to say "now go here and log in to MyEVE and
           get your single use key", they can phish that process easily
<Garthagk> phishing is a problem period I don't think you'll ever get
           away from it, the best thing you can do is try to compensate
           for it with user education
<Garthagk> user X who knows he should go to myeve and type in the site's
           name and get a private key is going to be safe no matter how we
           do it
<Garthagk> user Q who doesn't know how the process works is just going to
           trust the site, click the link, see MyEVE, log in, get some key,
           and be phished
Personal tools