Provided a user has chosen the remember me option while logged in last time into a web application,how does the web application server identifies the user next time when he logs in? The credentials are stored in cookies in the client side itself? That would make huge security issues right? Somebody please explain
3 Answers
Usaually the user's browser stores some cookies with a random string identifying the user on the server. More secure variants of this additionally check other parameters as the browser version, OS of the user and approximate location.
Basically, if you visit a webpage like facebook with a cookie, you get authenticated only with the random string in the cookie.
How this works: If you log in, the server generates this random string and stores it in it's database (togehter with other identification parameters). Additionally it sends this string as a cookie to the user's browser, where it is stored and delivered to the page with every request. So if there is a request with a random value, the server checks if it matches with the other identification parameters and - if so - accepts you as a logged in user.
This is a quite a broad question in that this could be (and has been) implemented in any of a large number of different ways. They generally involve storing a persistent cookie in the browser, and here are a few. The cookie might contain:
- An authentication token. (As Tokk described in his answer.) With state on the server (in the database, for instance) when a user returns you can tie the authentication token back to their user account.
- A user identifier. This is a stateless model that doesn't require you to keep a record of the session on the server. As long as the user continues to visit with cookie containing a valid user identifier, they're authenticated, and it no longer matters whether there are 10 seconds between page requests, or 10 days.
- Credentials. This is a hybrid stateful/stateless model is that you don't need to maintain a record of the session, but there's a different between an authenticated user (who has a session cookie) and an remembered user (who has the cookie with the credentials, but no session cookie yet.) This can be a massive security hole if the credentials are stored in the cookie in plaintext, and yes, some sites do (or have) done this. With proper encryption, well, I wouldn't choose it, but it's not much of a security risk in that case. (There is a bit of added risk in that the application is doing unnecessary extra processing of credentials, but it's a comparatively small risk.)
What is the big security risk in a "Remember Me" feature? Primarily that you're giving the user a cookie that is valid far into the future, and the window for abuse if that cookie is misappropriated is now much larger. So, with this in mind, care should be taken to protect this cookie. HTTPS should be used as a first line of defense, for instance, and the cookie should be marked as secure
. It's helpful if you have a stateful model to allow the user to forcibly end valid sessions when they no longer have a need for them, to curb potential abuses.
So the tl;dr is: Your credentials may or may not be stored in a cookie. If they are, and aren't properly encrypted, then this is a significant risk. This is likely not how a "remember me" feature is implemented on any given website but when in doubt, check your cookies and see.
The credentials are never stored either at the user end or at the server end(if configured as per security standards). If you want to keep your session active for a long time, or make sure your password is remembered next time when you login, then the browser communicates with the server to generate a random set of data that is stored in the form of Cookies.
When you visit the same site next time, the cookie which is unique to your login will be used to automatically authenticate and login to your account.
-
This is not necessarily true. There are plenty of implementations that store credentials in a cookie. In some cases, in plaintext, even.– XanderOct 2, 2014 at 10:19
-
-
Cookie is user end. And not always this is true. It depends on the developer's implementation. Oct 6, 2014 at 4:37