Timeline for Remember me feature: do we need a server side token if the cookie is signed by the server?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 3, 2019 at 10:10 | comment | added | Waiting for Dev... | Then I can revoke access to all the users changing the server secret . They just need to sign in again. It is an annoyance (but they have to sign in again from time to time when its remember me cookie expires, anyway), but not a risk. So it is a usability issue, not a security issue. I'm not trying to talk about generic good practices here, but just to focus on security in order to understand possibilities. Because, again, a middle way solution is to save the expiration time in the database and sign in the cookie. This way I don't need a hashed token and I can still revoke a single user. | |
| Apr 3, 2019 at 8:54 | comment | added | Marko Vodopija | You asked a question: do we need a server side token if the cookie is signed by the server? Answer is yes and for very exact reason you are excluding. It is a security concern since the token is access token or refresh token. These can be stolen. From security perspective, you need to have a way of disabling user access on backend. You said it is an admin backend with three or four users. Is it an internal company application? What if the user leaves the company? | |
| Apr 3, 2019 at 7:55 | comment | added | Waiting for Dev... | Why? What kind of attack prevents having a token in the server side that a signed cookie does not, for a persistent session? Forgetting now about the usability issue of not being able to revoke access to a single user in the system (because it's not a security concern, as I can revoke all users, which, for example, isn't neither a terrible usability issue for an admin backend with three or four users) | |
| Apr 3, 2019 at 5:56 | comment | added | John Wu | I thought you were talking about a cookie that helps populate the user name and password fields in your login page. Sounds like you are talking about an access token, literally a session cookie for a persistent session. That absolutely must have a matching token somewhere on the server side. | |
| Apr 3, 2019 at 4:42 | comment | added | Waiting for Dev... | The cookie only stores a user identifier, but it authenticates if sent to the server, so if the cookie is stolen the risk is very high. But it is the same for every other kind of remember me cookie. As you say, the difference is that with a server token you can revoke access to a single user. You can avoid it by storing in the server the expiration time, so you can expire it manually if needed. Of course, then you are very close to the server token scenario, but with a little less burden. Please, could you clarify the thing about the password manager? I don't see how it relates to it. | |
| Apr 2, 2019 at 23:32 | history | answered | John Wu | CC BY-SA 4.0 |