Question about persistent user session

Third Party Coronium
#1

First of all - thanks for last Coronium updates. Scope permissions is killer-feature for me  :slight_smile:

So my question is about login flow (via email and password)
 

Consider following flow:

  1. User enters data for registration, sending core.users.create

  2. Now we have userId and can execute all operations using this Id

  3. User close application and open it another day

I don’t want user to enter his password on every login, but saving userId in app data files seems a bit insecure for me.

The only solution I came up so far:

Store userId encrypted by some generic password like deviceId, so if someone will steal data files he can’t get userId.

Am i paranoid? Also I can store not userId, but generate sessionId for userId and check if session is active on api side

#2

You could use the core API to return a hashed reponse once the user has logged in/registered, to be stored on device.

Of course, you need a clientside login process that check for that hash and send it to serverside API for validation.

#3

That’s my concern: any data stored on device can be copied and used on another device. So storing some hash is almost the same as storing user_id

#4

one way or another you have to send something to the server for the user to auto login

you can make it more diffiult to copy by including deviceid in the logic but it is difficult to safeguard against knowing a users login.

#5

Hi,

Are you using client-side login or custom server-side logic?

-dev

#6

Hi, right now I’m using client-side

#7

Hi,

I can work on adding “sessions” functionality for the next release. But the user will need to log in at least once, per device. The session id would still need to stored on the device, but it would have a time limit and be encrypted/decrypted server-side (using some items from the client device as well as a server-side only key) so it would be nearly impossible to gain the users id. 

I’m not sure how long it will take to implement, but I’ll start working on it next week. You could attempt to do it manually as well using what I outlined. You’ll need to reissue a new session id when the old one expires, though that might not be totally needed. If you encrypt/decrypt the session id server-side with a custom key, then you’re pretty safe.

Coronium Core has LuaCrypto installed, which you can use to encrypt/decrypt an id with a special key of your choosing on the server-side, if you go the manual route.

But, I think it would be a good feature as it is, so I’ll work on adding it in regardless.

-dev

#8

Hi,

Actually, it may be possible to issue the session token on user.create so the initial login would not be required, I’ll see what I can do.

-dev

#9

Hi,

If you just wanted to implement something simple here is one example:

Server-side API

local api = core.api() function api.encryptSession( input ) local crypto = require("crypto") local sessionSecretKey = "1282a8d89b4d2ae466667b1e6e5f846183feb2c6405408a843a04cd7e1b706be" local sessionId = crypto.encrypt("aes256", input.user\_id, sessionSecretKey) sessionId = core.encode.b64(sessionId) return { session\_id = sessionId } end function api.decryptSession( input ) local crypto = require("crypto") local sessionId = core.decode.b64(input.session\_id) local sessionSecretKey = "1282a8d89b4d2ae466667b1e6e5f846183feb2c6405408a843a04cd7e1b706be" local userId = crypto.decrypt("aes256", sessionId, sessionSecretKey) return { user\_id = userId } end return api

Your client-side calls would look something like:

--# Encrypt local function onEncryptSession(e) if (e.result.session\_id) then local sessionId = e.result.session\_id -- Store the sessionId to a file (not shown) end end core.api.encryptSession({user\_id="\<user-id\>"}, onEncryptSession) --# Decrypt local function onDecryptSession(e) if (e.result.user\_id) then print(e.result.user\_id) -- the users id end end -- Get the sessionId from stored file (not shown) core.api.decryptSession({session\_id=sessionId}, onDecryptSession)

core.encode/decode is an internal api that isn’t documented at this time.

-dev

#10

Hi,

You could pass up some extra items from the device (id or something) to customize the sessionSecretKey even more.

-dev

#11

Thanks, I will implement something like this

Just not sure if asking for permissions to retrieve deviceId on android worth it

#12

cant have your cake and eat it mate  :smiley:

#13

Good point. I didn’t think about that.

-dev

#14

You could use the core API to return a hashed reponse once the user has logged in/registered, to be stored on device.

Of course, you need a clientside login process that check for that hash and send it to serverside API for validation.

#15

That’s my concern: any data stored on device can be copied and used on another device. So storing some hash is almost the same as storing user_id

#16

one way or another you have to send something to the server for the user to auto login

you can make it more diffiult to copy by including deviceid in the logic but it is difficult to safeguard against knowing a users login.

#17

Hi,

Are you using client-side login or custom server-side logic?

-dev

#18

Hi, right now I’m using client-side

#19

Hi,

I can work on adding “sessions” functionality for the next release. But the user will need to log in at least once, per device. The session id would still need to stored on the device, but it would have a time limit and be encrypted/decrypted server-side (using some items from the client device as well as a server-side only key) so it would be nearly impossible to gain the users id. 

I’m not sure how long it will take to implement, but I’ll start working on it next week. You could attempt to do it manually as well using what I outlined. You’ll need to reissue a new session id when the old one expires, though that might not be totally needed. If you encrypt/decrypt the session id server-side with a custom key, then you’re pretty safe.

Coronium Core has LuaCrypto installed, which you can use to encrypt/decrypt an id with a special key of your choosing on the server-side, if you go the manual route.

But, I think it would be a good feature as it is, so I’ll work on adding it in regardless.

-dev

#20

Hi,

Actually, it may be possible to issue the session token on user.create so the initial login would not be required, I’ll see what I can do.

-dev