It’s not about giving out secrets, sweetie. It’s about people stealing what they shouldn’t be stealing. We can all wish it didn’t happen, but it does and CCP’s support can give you the exact numbers on how often this happens (or rather how often they’re being told about it). I just wish they made it a bit more difficult with ESI, because you can be sure there will be players who aren’t just going to try, but who will abuse it as soon as they get the chance. Just the recent DoS attacks should show you that the world isn’t only full of saints.
If you are doing it right, it is very difficult to steal both the refresh and secret. If this does happen, CCP can shut them off by simply revoking access for that application.
Whoever signs the agreement for the application is responsible to keep both the refresh_tokens and the secret a secret.
You can “what-if” this to death, but this is a heck of a lot better than API keys floating around forever with little or no accountability over them.
It isn’t about if. It is about when.
I still think it could be a bit safer. For example not allowing multiple access tokens at a time and changing the refresh token with every refresh request would help you as a dev and your users in detecting when it happens.
Right now can you talk all about taking responsibility, but it means little when you cannot even tell when your client secret and refresh token got stolen. You’d likely be the last one to know before CCP asks you to have a chat with them about your app, at which point it will be too late.
They wont for long. Any violation of the developer agreement can cost you development access, revocation of your applications, and depending on how stupid you chose to be, loss of your game account. There’s a reason EVESkunk is going to die in just over a week. Malicious use of information obtained is one such violation. It also doesnt matter WHO is committing the malicious use, if it’s your app info being used to conduct the usage, it’s your ass on the line. The onus of securing your app credentials against loss, theft, or malicious agendas is on you as the developer. CCP does not care beyond their enforcement of the agreement.
So if your web service is so ■■■■-tier that you cant detect unauthorized activity, you deserve whatever punishment is coming your way. Same with desktop apps.
You don’t know when it’s been stolen. No speech of yours is going to detect it either. You are literally BS-ing yourself here and you’re using your agreement with CCP to do so. Give this a thought and then allow me to explain this to you with an analogy so you can understand what it is we’re talking here about…
When somebody steals the keys to your home then you notice it the moment you’re trying to find your keys or when you try to open the door. If you’re lucky then only your keys are gone, but nothing may have been stolen or destroyed yet. Might also be it has and it’s already too late.
But when keys can be copied as easily as it is the case right now with the tokens, then you’re not going to notice it when your keys are gone. You can go back to your home and unlock your door and you still won’t notice that somebody now has a key to your home. And only when a thief takes or destroys something that was important to you will you notice that somebody was in your house. Might also be somebody just left a bunch of nice flowers for you.
Statistics however tell us that by making it harder for keys to be copied are we protecting ourselves better. This is what we’re talking here about. Let me know when you’re done with speeches and if we can talk about this seriously.
Let us know when you want to use relevant examples @Whitehound. Then we’ll take you seriously. Oh, let us know what apps you’re developing too. It’s clear we dont want to use them if you’re so lax about keeping things secure.
You don’t like what I’m discussing here or do you just don’t understand it?
And stop with the speeches. You’re literally just practicing speeches and you’re now doing it in plural, mate.
1 Like
Hello everybody,
after sleeping over twice i did some programming.
Summary
def SSOAuthentification(self, CodeToken = "", auth ="refresh"):
SSO_TOKEN_URL = "https://login.eveonline.com/oauth/token"
headers = {}
headers['content-type'] = "application/x-www-form-urlencoded"
headers['authorization'] = "Basic clientID + Secret"
body ={}
if auth == "refresh":
body['grant_type'] = "refresh_token"
body['refresh_token'] = CodeToken
elif auth =="new":
body['grant_type'] = "authorization_code"
body['code'] = CodeToken
else:
print ("Error wrong type!")
return {
"TYPE":auth,
"Code or Token: ":CodeToken
}
if CodeToken !="":
request_made = requests.Request('POST', SSO_TOKEN_URL, data=body, headers=headers)
request = request_made.prepare()
request.headers
request.body
req = requests.post(SSO_TOKEN_URL, headers = headers, data = body)
return req.json()
else:
print("No token or authentification code!")
It is working just fine. Wether it is a AccessCode from the EVE SSO Page or a RefreshToken from the local datadump on the users HDD. I know there are ready made Libs for Python for OAuth but is want to learn it step by step. This works on 3 different machines. The first one is my engineering PC, second one is my gaming rig and the third one is from my corp mate.
The only problem for data security in my oppnion is the stored clienID + secret, but as told above ccp is working on this for desktop apps. Keeping you Refreshcodes a secret on desktop apps is the job of the user. If you give a AccessCode to someone else, it is your own decision. Giving someone a RefreshCode is not nessesary. Maybe CCP should keep track of all the AccessCodes so you can see if it got redeemed and revoke single streams.
I wonder, what happens to the RefreshCodes i used for testing which i didn’t save. Are they still active or do they get invalid after some time when no new AccessToken is requested.
Alexander
One can use an old refresh token, i.e. from a previous SSO session, and use it instead of a newer refresh token. It doesn’t become invalid, but still returns new access codes.
And because a refresh token doesn’t change during a single SSO session is the first refresh token the same as any of the following ones that you get from a refresh request and so there it obviously cannot become invalid.
At least this is true for some time. I don’t know if there is an ultimate time limit on their validity.
The OAuth2 authorization isn’t any saver than a classic login/password check. You’re only made to go through hoops for no additional gains.
You should not store the secret in the app. You should have the user provide their own in the short term. It’s annoying, but the way to go.
You should revoke the old refresh tokens, either using the ui, or with the /revoke endpoint.
http://eveonline-third-party-documentation.readthedocs.io/en/latest/sso/tokenrevocation.html
1 Like
But i cant revoke the RefreshTokens, if i did not save them. For testing, i simply requested a AcessCode and redeemed it without saving the Access and RefreshTokens.
You can, but you must revoke at https://community.eveonline.com/support/third-party-applications/ for all old refresh tokens to become invalid.
Also, when you do it properly, meaning you revoke old refresh tokens from your own app, then you’ll always have to send a POST request to the OAuth2 server, which is going to cost you 100ms-200ms, and this is without retrial, because your request can always fail due to the nature of the Internet.
This would be better if it was done automatically each time a new SSO session is initiated. We do get a new refresh token there and I wonder who still would want to use an older one at this point. Best would be to revoke the refresh tokens with every refresh request and to return a new refresh token instead of just sending a copy of the token we already have.
I’ll make it a feature request at some point as I already have something else on my mind, too, that I want to ask of CCP.
Comments, as long as they’re meaningful, are always welcome.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.