Are our tokens secure?

[michael]

Just wondering, that we can look inside our tokens, which i thought is just some sort of session id.

speaking of:

atob(data.token.split('.')[1]);

that produces:

{"email":"admin@substance.io","created_at":1432401077298,"updated_at":1432401077298,"data":"{}","iat":1432458804,"exp":1432545204,"iss":"admin@substance.io"}

so if somebody grabbed a token, they would know the email address associated.. well but maybe that's anyway a problem, if you have the session hijacked, then getting to the email and userdata is easy anyway.

just loud thinking.. ;)

[Integral]

Hey! If we have any sensitive data, then we must crypt this token.

On Sun, May 24, 2015, 12:16 PM Michael Aufreiter notifications@github.com
wrote:

Just wondering, that we can look inside our tokens, which i thought is
just some sort of session id.

speaking of:

atob(data.token.split('.')[1]);

that produces:

{"email":"admin@substance.io","created_at":1432401077298,"updated_at":1432401077298,"data":"{}","iat":1432458804,"exp":1432545204,"iss":"admin@substance.io"}

so if somebody grabbed a token, they would know the email address
associated.. well but maybe that's anyway a problem, if you have the
session hijacked, then getting to the email and userdata is easy anyway.

just loud thinking.. ;)

—
Reply to this email directly or view it on GitHub
#14.

[michael]

I think i just want to customize the response of /authenticate

It should give us the token (that should not have sensitive information inside) it's only used to send along with the header to identify the token on the server. I think that's how we should do it... in order to display some user profile information we can return a user object that only has the name in it, so we can display it in the user status bar.

Will sketch the specs for the API, and you review? In that move we can also switch to username as primary key instead of email.

[Integral]

good!
we could also query api for user object

On 24 May 2015 at 12:39, Michael Aufreiter notifications@github.com wrote:

I think i just want to customize the response of /authenticate

It should give us the token (that should not have sensitive information
inside) it's only used to send along with the header to identify the token
on the server. I think that's how we should do it... in order to display
some user profile information we can return a user object that only has the
name in it, so we can display it in the user status bar.

Will sketch the specs for the API, and you review? In that move we can
also switch to username as primary key instead of email.

—
Reply to this email directly or view it on GitHub
#14 (comment).

[michael]

That we should also have I think. But nice when /authenticate returns the minimal data so we don't need another request.

[michael]

One more question regarding session tokens: What happens if a user wants to login on two machines at the same time? Since the user token is stored in the user table there can only be one right? So what would happen is that if you login on another machine.. you get kicked out at the first machine... i guess that's fine for the beginning.. just wanted to understand where we are.

[michael]

I've changed the authenticate method to what i need. @Integral please review!

[Integral]

@michael, we don't store token now and perhaps we don't need this at all. So no problems with different machines...

[michael]

Ok. most importantly now login stuff works :)

So we can move on with more interesting things like actually storing documents.

I created interface for making headings, had to reimplement this on top of new substance architecture.

[michael]

I'll be in the kitchen for a bit. Back soon to help with integration of storing docs. Nice this system will be soon! :)

I think we should reactivate substance compiler module, so people can make templates for their journal frontend.

[Integral]

Hey!
Regarding expired tokens... Well, i think someone could steal token from
console. And I don't know what we could do here, because of tokens didn't
store any information about client like cookies. If we'll allow to
autoupdate token expiration date or regeneration without password than
someone who stole it will be able to use it always...

On Sun, May 24, 2015 at 3:24 PM Michael Aufreiter notifications@github.com
wrote:

I'll be in the kitchen for a bit. Back soon to help with integration of
storing docs. Nice this system will be soon! :)

I think we should reactivate substance compiler module, so people can make
templates for their journal frontend.

—
Reply to this email directly or view it on GitHub
#14 (comment).

[michael]

well i think what is a good compromise is that the token expires after some inactivity. we can make this even a shorter time period (e.g. when not using the system for 2 hours) you get logged out. we need to talk about security anyway (speaking of one-time passwords etc.) but in this early stage, users are responsible to be careful with their passwords.

[michael]

Also idea i had: maybe not let the user choose a password at all, if you create a new user a generated strong password is used that you need to tell the user somehow in a secure way. we can also enforce the generation of a new password every few months or so.

anyway.. not now! :)