Hi
I’m trying to create a secure login to a form-web-app. I’m doing this to learn more about web programming.
What is your ideas on this?
I’m playing with the: Gorilla Sessions package (http://www.gorillatoolkit.org/pkg/sessions). I wonder if I create a session-cookie, that will live in 20 minutes, httpOnly, httpSecure. Is it secure enough to store a username in it? Or should I implement a sessionID (uuid)?
Best regards Micke
In general, there is no such thing as secure anything, it is secure in theory because they assume nobody has the computational ability to break the ciphers. SHA was said to generate unique hashes, but now, in 2016, we had the first SHA collision on Github.
Store the session ID rather than the username, also, I don’t think usernames are really confidential, but still, it is better.
The package you’re using offers encrypted cookies (to prevent reading contents) and also has an HMAC I think (to prevent tampering), so just make sure you use both those options.
Hi
So it is “better” to store a sessionID in the cookie, instead of username.
I have implemented this “design”.
Then I create the cookie, I store a sessionID (uuid) in the cookie. At the same time I add the sessionID to the db, sessionID = userName. It is now possible to get userName from sessionID. Then the user logoff, I clear the cookie and the sessionID in the database. The problem is, then the cookie expire, the sessionID will still exists in the database. no valid cookie exists. Ower time the database will have alot of “dead” sessionID:s… Should I add a “last access” to the sessionID in the database? And then run a background job to remove “old” sessionsID:s?
I’m curious, what you thoughts is?
Best regards Micke
You don’t need to store sessions in two places if they are small, just put them in the secure cookie encrypted.
You can create on server JWT token and store this token into cookie instead of sessionid. This JWT token contain user and password (hash). It allows you sessionless architecture on server (you could restart servers, scale server, etc…). Some GO server frameworks support it (Echo).
I do not think that is very accurate. JWT tokens cannot be revoked.
They cannot be revoked, but they can have a relative short lifetime by setting the exp claim. The gateway has to detected an upcoming expiration and use the token for a regeneration, then with maybe changed rights. In case of a locked user or a too loong inactivity the token expires and a user has to re-login.
I am not sure I understand how that works. How do you detect an upcoming expiration without storing tokens since we are talking about sessionless architecture here?
What if the user’s account gets compromised? There needs to be a way to revoke the token. That means blacklisting tokens on server side which essentially defeats the whole sessionless architecture.
Also prompting the user to re-login is not a very acceptable behavior for mobile applications. That causes extra problems.
While in usage we steadily compare current time and expiring time. In case of an access in the 5 minutes before expiring the client is told to retrieve a new token. In case of no access it simply expires, like a session timeout.
The callers address is part of the claims when creating a token. The signing ensures the a change of this address will be detected by the verification.
Thanks for critical questions, will help us to discover possible flaws.
I am only arguing about the word “sessionless”. In practice it is not really possible to have a sessionless architecture with JWT especially for web apps. As soon as you need a way to logout the user or revoke a token then you need to start storing the tokens in a database or Redis.
Yeah, that’s right. In case of an active logout by an administrator at least each gateway component needs the knowledge that a technically active token is now invalid. Thankfully we never needed this kind of behavior, short expiring times and recreations of tokens have been enough.
If it helps, I have code you can look at which implements databaseless JWT-based authentication, with session revocation and encrypted and signed user data.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.