3 ms·
I think more context is needed to understand what your web application does. When you say web token, I assume you mean JWT, which uses a process of encoding/de
by matt_s 6y ago
I think more context is needed to understand what your web application does. When you say web token, I assume you mean JWT, which uses a process of encoding/decoding and can be hacked.
If an attacker can interfere with the JWT/cookie on the client and change the user id they can become any user on your system.
Don't put any user info on the client (JWT/cookie page rendered stuff is fine), just a hash that refers to the session id. This would make it harder for someone to change ids or guess usernames. And use HTTPS for all traffic.
Its okay to use lightweight sessions, a hash for the session id and a user id in a sessions table on the server should be enough to keep track of who is who.
Most web frameworks have this problem solved so maybe look into that for whatever language you are using (unless this is a comp-sci quiz question testing your understanding of sessions/security, haha).
- m33k44 6y ago> I assume you mean JWT Yes. > JWT/cookie page rendered stuff is fine Please could you elaborate on this? > And use HTTPS for all traffic. Yes, that is done. > unless this is a comp-sci quiz question testing your understanding of sessions/security, haha No it is not :)
- matt_s 6y agoWhat I meant was don't put identifiable user information (ids, email addresses, etc.) on the client in a JWT or cookie and use that as a session identifier. If the JWT or cookie gets hacked then someone can impersonate anyone on your system. Putting their info (email, name, etc.) on a user profile type of page should be fine if your app has a need to do that.
- m33k44 6y agoI am just storing ephemeral id and username in JWT and put the encrypted id in a separate cookie.