search

standardnotes / syncing-server

[Deprecated: Use our new Node server: https://github.com/standardnotes/syncing-server-js]
https://standardnotes.org
GNU Affero General Public License v3.0
209 stars 48 forks source link

Session tokens develop branch #117

Closed robjaq closed 3 years ago

robjaq commented 3 years ago

I wanted to try to understand how authentication and sessions worked here. The Sessions.md file is very much appreciated, since I do not know ruby well. What I figure is that the access token and the refresh token are stored as they are.

  1. Therefore if an attacker were to gain access to the db silently or backups(depending on how their stored) then they would be able to get hold of anybody's session tokens and use them.

  2. Also that searching for the token in the db can perhaps be open to comparison attacks.

I am reading this book: Password authentication for web and mobile apps by Dmitry Chestnykh, https://dchest.com/authbook/

And it recommends to uniquely generate two parts for a single token, an Identifier and a Verifier. You would then concatenate both of those values and send it to the client. You would store and index the identifier, and hash(SHA-256) of the verifier and store that separately. To authenticate the user, search for the identifier and compare the hash of the verifier in the request to the hash of the verifier in the database using constant time comparison.

So I guess you would do this for both the access and refresh tokens. Is this realistic? Or am I missing something?

JaspalSuri commented 3 years ago

Hi @robjaq,

I've assigned some members of the team to look into your questions and they will get back to you within a few days or by early next week. 🙂

moughxyz commented 3 years ago

@robjaq good point, hashing the access_token and refresh_token before storing on the server would be an improvement. The identifier would just be the session's UUID. I'll look into this more but sounds like we can make this change before we go live with develop.