- 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]
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.
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.
<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
<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
<Garthagk> yeah, we'd basically define a URL, something like... http://myeve.eve-online.com/openid.asp?userid=2134123 <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 http://myeve.eve-online.com/openid.asp?userid=2134123 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 (http://myeve.eve-online.com/openid.asp) 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