Character Login - Custom Browser SSO

[ficti0n1]

To authorise characters your app uses it's own browser module

There is no way to check source or URL this is going to. I know you could look through this repo, but why not use the users browser. Would be a lot safer from the users perspective.

I stopped testing at the point as I don't want to put my password into a custom browser like this and many others will do the same.

[PrometheusSatyen]

Edit: I've revised my stance on this, please see later comments.

Hi @ficti0n1,

Using the user's browser does not grant any additional security whatsoever, all it gives is a false sense of security.

If I wanted to steal tokens, I could simply use the exact same screen I'm currently using with a redirect to eveauth-cerebral://callback (this is the URL used) and then simply dump the tokens received and send them off to a server I control.

The only way to determine whether the application is maliciously using your tokens is to examine the source code, or have someone you trust examine the source code.

Also, in a future release, (I'm currently targeting v0.6.0) all users will have to create their own Developer EVE account and input client id/secret for it. As this involves setting up an authorized callback URL, the application will be restricted to that callback URL and you can be assured that it cannot redirect elsewhere.

[ficti0n1]

My issue is that no other app asks you to supply your password to the tool itself. This app directs you to the login page using it's own browser tool where you input your username and password.

I appreciate that this app hasn't been posted anywhere and nowhere have you asked anyone to test it for you, but I really do want a decent evemon replacement and from what I can tell this could be it, the screenshots look great.

[PrometheusSatyen]

OK I can see the concern now, essentially the worst case scenario for an application which uses the external browser in terms of credential interception is that they get a token with certain scopes granted, whereas with an embedded window the worst case scenario is your actual password being intercepted.

So:

1. The application is open source, and the code which handles the embedded browser authorization is in fact extremely short and easy to examine: https://github.com/PrometheusSatyen/Cerebral/blob/master/src/helpers/CharacterHelper.js
2. Implementing an external browser authorization flow will involve complexity such as a local HTTP server, so it is a reasonably significant workload.
3. The external browser flow is clunkier and slower than an embedded flow, there are users who will desire the embedded flow, as there are users who will desire the external browser flow. I'd like to accommodate both demographics.

So here's what I'm going to do:

1. In the next release I'm going to see if I can get the address bar to display in the embedded browser, this doesn't provide full assurance that passwords aren't being intercepted but it is an improvement.
2. I'm going to aim to implement an optional external browser authentication flow, which can be enabled from a Settings panel in Cerebral by users who desire it. This won't be a priority but I will get to it at some point.

[ficti0n1]

evernus and jeveassets both manage this but via routing on their own websites. I think both devs (pete butcher & goldengnu?) had hard times with this but sadly I think thats just how it is with local eve apps post-SSO. #devfleet might be able to help with this.

Again this is your app but I think once it's made 'public' it will be crucified over this login point. But if it's just your app for you and friends then it's fine. I'm not here to give you grief, I'm here because I want this app to do well as the UI looks pretty slick and the app itself seems to tick all the boxes I and others would need after XML and evemon goes down.

edit: completely unrelated but if all of the apps files, config, tokens etc could be stored in the installation folder it would make it a lot easier to transfer between PCs for those who would want to sync it between devices using cloud.

[PrometheusSatyen]

I'm definitely not going to route the SSO flow via a website I control, that's a far worse security concern than anything brought up in this issue since I could be intercepting tokens without any way for anyone to check (since I could be doing it with code on my server that they can't examine).

What I can do is start up a local HTTP server on a non-privileged port and then direct the callback from the browser to that HTTP server to grab the credentials. This is my plan for the opt-in setting for the more paranoid among us. I would've guessed that this is how Evernus/jEveAssets handle it, if it's not then v0v but I've no idea why they'd choose a more complex/less secure method.

Cerebral has been in testing with the PanFam (PL/Horde) and I haven't had any screaming about embedded authorization flow so far. It's just silly to assume that I'd risk my EVE account and several hundred billion ISK by putting malicious code into an open source application online.

Re: The other thing make a separate issue and I'll talk about it.

[Seavert]

Local server can have problems with OS, antivirus or other limitations. My suggestion is to allow custom callback address along with id and secret. App starts auth in default browser. You get string like "127.0.30.30/abc/?code=123&state=456". Then you manually copy it to callback field of app and click to add character. It is safe, clean, can be done everywhere and much easier to implement.

[PrometheusSatyen]

@Seavert That's a clunky and horrible auth process, and I will not implement it that way.

Local server can have problems with OS, antivirus or other limitations.

Please elaborate here, if you can find an OS/antivirus that blocks establishing a HTTP server on localhost on an unprivileged port I'd love to hear about it.

[rohimma]

you can use this: https://www.npmjs.com/package/electron-oauth2

[PrometheusSatyen]

@rohimma That library basically does it the exact same way I do already.

[rohimma]

@PrometheusSatyen no, with this library you will use an external browser