Support for multiple accounts under the new authentication scheme

[atkinsj]

This is a big thing missing when moving to centralised CREST SSO. Scouts have multiple accounts and alternate between them: having to logout and relogin constantly is a massive hindrance to usability.

We need a way to associate a Pathfinder login with multiple accounts.

[exodus4d]

Yeah this is indeed a Problem. It took me some time to finish #131 (comment) first :(. All new features are now implemented for v1.0.0RC3. Now I´ll focus on this Issue and some smaller bugs before it is ready to release it.

[atkinsj]

That's awesome -- thanks again for all the hard work, I hope you don't
think I'm giving you a hard time! I'm passing back feedback from a bunch of
our scouts.

On 24 April 2016 at 11:29, Mark Friedrich notifications@github.com wrote:

Yeah this is indeed a Problem. It took me some time to finish #131
(comment)
#131 (comment)
first :(. All new features are now implemented for v1.0.0RC3. Now I´ll
focus on this Issue and some smaller bugs before it is ready to release it.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#138 (comment)

[exodus4d]

Oh no, I appreciate our feedback! Unfortunately I don´t have the time to play a lot, therefore user feeback is very important for me!

How it works

• Any user has to login via CCP´s SSO*, when using *Pathfinder, with a character, for the first time (this should always work on the current develop branch.
• User gets a sort Cookie notification, which can be accepted (or not). Cookies will not be send to clients that have not accepted this hint. (EU legislation on cookies)
• If login was successful a login-cookie is send to the client
• When he comes back, Pathfinder will check for existing cookies and provide direct character login for valid characters.

Technical information

After reading a lot about "long term User authentication" and security concerns, I really liked the way described in this article "Implementing Secure User Authentication in PHP".(awesome article!)

• Any Cookie is stored on a new DB table character_authentication which is used to verify the validity of each Cookie (Client side manipulation e.g. changing the "expire date" will result in an invalid Cookie,...)

• There is no "blank" data stored on a Cookie (like DB ids,...). So there is no chance of "guessing" other Cookie data. No way to get additional information about the App (e.g. number of users/characters which would be the case when we would use DB ids,...)
• Expire time can be set in pathfinder.ini (default: 30days)
• Each character has its own Cookie. The Cookie name is unique ("char_" . md5([CHARACTER_NAME]). The name does not have to be secure, it just should be unique :)
• The Cookie value of it consists of two parts
  • A unique selector generated out of an random initialization vector which used to identify the validity of the Cookie against the DB
  • A validator which represents the character name. The hashed (sha256) version of this validator is stored in the DB column and is used for an additional layer of security

• Even if somebody breaks into the DB, it is not possible to generate valid Cookie information just from the DB tables
• Cookies are set with httponly = true setcookie(); to protect against JS manipulation.

Cookie verification process

1. Read all character log in Cookies
2. Check Cookie format (selectorand validator must be present)
3. Select DB column from character_authentication table where selector data matches appropriate column
4. Check if Cookie expire time matches DB expire time in character_authentication
5. Check if character "exists" is "valid" and "active"
6. Check if validator column character_authentication table matches sha256-hashed version of Cookie validation data
7. Try to update Character over CREST (update access_token, e.g. update corp/ally,...)
8. Check if character is authorized to log in (e.g. corporation has changed/not on "white list", or App access was changed/limited to specific corps/allys,...)
9. Login :)

[atkinsj]

I'm glad the article was helpful; from a security standpoint your implementation looks solid but I'll have a closer look today as it's not currently working for me (possibly because you set the cookie via javascript instead of PHP and I have some addons running).

Would it be possible to set a default character so that when you land on the homepage you get automatically logged in? You could then use the character selector at the top to switch accounts as well.

[atkinsj]

Hmm, I might be crazy, but I only see the EU legislation cookie actually being set in your commit? None of the char_ cookies appear to being set at all. I'm also not convinced that the EU legislation cookie is actually still a legal requirement.

EDIT: Nevermind. It was an addon.

The only thing you're missing that I see from a security perspective is the ability to revoke cookies. Clicking the "Logout" menu item should destroy the cookies and remove them from the character_authentications database table. You can destroy a cookie by setting it's expiry in the past as in:

setcookie($cookiename,'',strtotime('-1 year'));

Given that a logon gets you CREST access to the users location, you should add a menu item that destroys all authentication tokens for that character. That way a user can choose to make all the cookies that are out there in the wild (potentially on other computers, Internet cafes, etc) invalid from any current logon session.

[exodus4d]

The first cookie (which is set when you confirm the "set cookie" hint at the bottom) is set by javascript.
The character cookies are set by PHP when you log in by SSO: sso.php#L208 in this function
setLoginCookie();

The characters you see on the homepage are already "verified" and updated by CREST, by checking your cookies. This is done by Ajax requests for each character cookie on document.onload. I implemented it that way, because it takes about 100ms to perform CREST calls and DB updates for each character. -> Otherwise a user with 10 characters would wait about 1s before the page gets initial loaded.
Just click on one of the character images and you are logged in.
But you can still click the SSO button, for log in a fresh character. This will also update cookie data of an existing character you already have access to (e.g. you click the SSO button instead of the character image,..)
I don´t think we need a "default character", it is just one click to select a char.

I´m not completely done with this task. There are still some things missing:

• When a character was sold -> all existing character_authentication relations must be deleted
• The getCookieCharacters(); handles all the verification process of character cookies (invalid cookies are deleted at the end). But we need a new cronjob as well which deletes expired cookies (just to keep the DB clean). This should be done on EVE server downtime
• You are right, a character "logout" should also delete cookie information from DB
• The character switch (on the map page) is currently not "in line" with the one on the homepage (and not using those cookie information). This will be unified.

[exodus4d]

Because Pathfinder gets more depending on CCPs CREST API by the time. It would be helpful to see/check CREST status and EVE server status information. In case CREST is down, you will not be able to log in and use the app.
Therefore a implemented a small notification panel on the login page:

[exodus4d]

dfd1e85 Added new "cookie logout" functionality. -> If you manually logout (click on the menu entry), all server-side stored cookie information are deleted, too. If you get automatically logged out (e.g. on server errors), your login cookies are still active.

• This will prevent anyone else to login this character with a valid cookie
• This will delete your cookie for this character
• This will not logout any character from the active user

If there is already someone else logged in (with an active SESSION), he will logged out as soon as PATHFINDER.TIMER.LOGGED (default: 240 minutes -> pathfinder.ini) expires. This may can be improved in the future but requires some additional programming to work.

[mrurb]

I woulds suggest making the Accept cookies notice a bit bigger and more obvious.