In a web application where you have to log in, we want to implement a feature that shows recently used accounts for the device.

The login screen will display a list of the usernames of the accounts that have recently logged in via the current device. It is about the same as the Google or Facebook login.

The difference is that we always ask for a password. The feature is therefore not intended to simply click on the account and you are logged in. We always want the user to type in a password. The usefulness of the feature is that you do not have to keep typing in your username / email address, but can click on a recent account and enter your password. To identify the device, a cookie is required in all cases as far as we can imagine.

Now the question is: How will we store the details of recently used accounts? Two options we can think of:

  1. Store a unique identifier "token" in a cookie. Store on the server which recent accounts are associated with that cookie (i.e. device) and then display these usernames on the login page to click on.
  2. Store the recent accounts in the cookie, so on the device itself.

With option 1 we think of the following threats:

  • If the cookie containing the token is stolen, the cookie can be impersonated on any device, thus spying on another device/location to see what recent accounts are being used on the actual device the cookie was intended for.

Option 2 seems to have the greatest risk of problems, because:

  • With many recent accounts, the data in the cookie could become too large (when for example also some metadata and/or "last login date" is contained).
  • If a username changes, the old username is still in the cookie. Unless the cookie is updated when changing the username in the account settings.
  • With option 1, the token in the cookie can be invalidated on the server, after which the cookie can no longer be used. This is not possible with option 2.

In all cases we do not want to be "smart" by using information such as IP address or screen resolution etc., because this information changes regularly, on mobile internet devices anyway and also with people who use a VPN.

How should this feature be implemented?

2 Answers 2


The better solution of the two is to only store a reference to the usernames in the cookie, simply because this allows you to clear the data after a specified time and reduce the risk of accidentally leaking it (e. g. on a shared device). If you store the usernames in the cookie itself, they will exist in the browser's cookie jar until either the user deletes them manually or the browser decides to delete them. You can of course set an expiration date, but that only means the cookie will no longer be sent in subsequent request. It can still remain in the cookie jar for an indefinite time. A third option would be to encrypt the usernames in the cookie with a key stored on the server, but this seems overkill.

Make sure to set the appropriate cookie attributes

  • The cookie should only be transmitted over HTTPS
  • It should only be sent to the domain and path where it's actually needed (i. e. the log-in page)
  • It should not be accessible by JavaScript, unless this is actually needed.

You should also give the user the option to opt out of this feature if they decide that they don't want the usernames to be remembered (e. g. on a shared device).


First thing to consider: what's your threat model? Is there anything you're worried about other than "the fact that a user logged into your site might be revealed"? That's generally only a minor privacy breach - not completely innocuous (and how innocuous it is depends on what, exactly, your site is) - but it's not something where extreme caution is needed.

You probably shouldn't use a cookie here at all. The server doesn't need to know what accounts have recently been used by that device, and there's no reason to store data that the client needs but the server doesn't in a cookie; that's what local/session storage is for. Make the login page check the local storage for a list of recent accounts, and display them for the user to choose. Simple, secure (assuming the machine isn't shared with people who you'd want to keep the login history private from, but your choices wouldn't be any better there), no need to transmit it over the Internet at all. You can use client-side logic to update the list of stored accounts when somebody changes their username, you can have a button to remove users from the local record if you want (though users can also just clear site data to achieve the same thing), and there's no practical chance of running out of space.

Definitely do give the ability to avoid storing the fact that a user logged in. People should use private (incognito) browsing when they care about that, but sometimes they don't; it's best to make the choice explicit.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .