I've been developing web apps for quite some time now. While making websites, the "remember me" feature is one of the most trivial (read as must-have-for-clients) feature to be implemented. Until today, I was just using the default implementations provided by the ASP.NET authentication system - which I must say, is pretty secure (as long as one does not fiddle with the provided default implementation). But today, I just got curious about the implementation details of this feature. I did some research, and went through a few related articles:

Troy Hunt- How and how not to build

Troy's article basically comes down to the conclusion that, if possible you're better off not implementing this feature at all, as no matter what, despite your best efforts, you're always going to have to come down to a security-related compromise. Similarly, Barry's article, based on Miller, Charles design, he has some very nice strategic steps to minimize the attack surface and complicate the attack vector.

Why are the cookies not signed by the browsers? Wouldn't it be best if each browser-client (mobile/desktop/whatever), had their own unique GUID kind of thing, which was not to be modified (under any circumstances), and then they can send their GUID to the servers, and the server could then use as the key-value to decrypt/verify any client-side information (cookies/querystrings)?*

Wouldn't this solve the issue of session-hijacking/cookie-hijacking completely, as a cookie from one browser would then be totally useless for another browser?

  • 1
    Setting the ;secure and ;httponly flags will also help prevent cookie highjacking.
    – k1DBLITZ
    Commented May 15, 2014 at 13:30

4 Answers 4


You'd need to secure the GUID transmission (consider the possibility of a server posing as another server, or man-in-the-middle); I strongly suspect that this would rapidly evolve to something needing asymmetric encryption and, finally, a pared-down version of HTTPS. Since full HTTPS is already available, it seems a duplication of effort.

On the other hand, using a GUID (which acts, when all is said and done, as a [temporary] shared key) will not defend against the client being compromised (malware, 'black' forensics, possibly even social engineering depending on how the interface is designed). For this, you would need a local trusted escrow system - a sort of secure smart card, so that you cannot read and duplicate what's actually inside, while being able to prove to a third party (the server) that the data is there.

But at that point, would we really need cookies? We'd have a smart card with our user login data held securely; it would then be far simpler to link the session not to the browser, but to the username. The "remember me" function would be undertaken by you plugging in the smart card.

Another and easier possibility would be, as user lesto suggests, to store the privately agreed secret in a password-protected area - a "keyring", "portfolio" or "wallet" - just like form passwords. The user unlocks the keyring with a master password, then the browser can authenticate.

But the whole scheme can be implemented in a more direct way by forcing secure cookies to be stored in the secure area together with cached passwords. On receiving a cookie through a secure connection, the browser would request the user to unlock the secure area, find a cookie with the same name for the same domain already existing, and would then repeat the request, this time sending the expected cookie. From the user's point of view, he goes on a secure site with the "Remember me" option enabled, a browser popup appears requesting the master password, and next thing he knows he's logged in.

An attacker would have no way (weeeellll...) of accessing the HTTPS exchange, and if he were to seize the computer, he would find cookies and passwords in a AES-256 encrypted block for which he lacks the master access key.

  • that makes a lot of sense. But what if, there's a central repo/organization that validates the browser's-identity first ? In the same way, the DNS translates url-text into numbers ? All done internally, without any intervention. Even for https, adding one additional intermediate step. So that, all http requests, goes through, browser-validationServer-ActualServer ??? Just asking, I'm just trying to brain-storm here, and get my misconceptions cleared. :) I know, I'm starting to sound stupid here, but still :).
    – MrClan
    Commented May 15, 2014 at 8:37
  • @MrClan and lserni see my answer, first auth can be a classical login, but then httpS key can be stored (server and client side), and because asimetric works, every message can be securly signed client and server side, so no ajack may be possible unless attacker got one of the private key
    – Lesto
    Commented May 15, 2014 at 9:12
  • @lesto how do you suggest to store the httpS key on client side ?
    – MrClan
    Commented May 15, 2014 at 9:18
  • @MrClan it have to be done by browser, so it is his implementation problem. All browser store password if user want, so that same storage may be used. On linux i use a "portfolio" appplication that store password, and many software (like chromium) actually use it if found. That is a better solution, because on the back of this "portfolio" program, there can be anithing, from a cripted file to a quantum system ;)
    – Lesto
    Commented May 15, 2014 at 9:23
  • @lesto, what you propose is feasible. I have expanded my answer and tried to simplify the scheme, as I feel it would take very little to implement it with minimum disruption to user experience (of course, it would require modifying the browser).
    – LSerni
    Commented May 15, 2014 at 12:06

What you are suggesting has different privacy and security implications and would not work in general as you can't guarantee the authenticity of your mentioned GUIDs:

  1. It can be captured easily, you only have to redirect user to any webserver you have access to.
  2. There is nothing preventing someone from writing a custom browser (or modifying the source code of existing one) to fake the GUID, so your points "which was not to be modified (under any circumstances)" wouldn't really work.
  3. There are various other privacy implications with this solution such as being able to track someone uniquely (if you don't look at previous points).
  • It would be more like an IP-address of the user, which as we all know won't always be unique. So the privacy issues would be more-or-less equivalent to having an unique IP, as no other information is revealed/sent to the server. Please also see my comment on, @user45634's answers.
    – MrClan
    Commented May 15, 2014 at 8:13
  • Well it would be even more detailed than that, as you would be able to identify different clients coming from the same IP, which is the case with IPv4 most of the time.
    – user43488
    Commented May 15, 2014 at 8:25
  • but users are normally okay with that, aren't they ? Their, browserclient info is transferred to-and-fro all the time. Isn't it ?
    – MrClan
    Commented May 15, 2014 at 8:36

Wouldn't this solve the issue of session-hijacking/cookie-hijacking completely, as a cookie from one browser would then be totally useless for another browser ?

Not completely. What if someone hijacks your cookie on the same computer? (Public computer). AND, who sends the GUID? The browser itself, so it leaves a big vulnerability, as you could also copy the GUID. Never trust user input!

I'd suggest you to have a look at HttpOnly : https://www.owasp.org/index.php/HttpOnly

  • what if, the browser sends the GUID, in a let's say (a readonly HTTP-Header[just saying]) ? On a public computer this won't solve the issue, but atleast the malicious user, then needs to have access to the same machine+browser. Wouldn't this reduce the chances of getting hijacked considerably ?
    – MrClan
    Commented May 15, 2014 at 8:09
  • 1
    No! You can send whatever you want, there's no such thing as a readonly HTTP header. Every security check has to be on the server side. This would nearly be the same as the heartbleed thing. You send something, the server trusts you, and gets hacked. Have a look at HTTP queries and how you can send them. You could make your own browser or even alter network packets before sending them, so every HTTP parameter is fully alterable.
    – Corneliux
    Commented May 15, 2014 at 8:18
  • I'm all about what-if right now. What if there was indeed an, readonly http header ? :) What would be the implications, then ???
    – MrClan
    Commented May 15, 2014 at 8:40
  • What if we killed everybody who knows how to modify a http header? What would be the implications? ^^ Ok, i'll stop being silly... Security has to rely on strong mechanisms such as authentification or cryptography. You can't just force everybody to use a given browser that sets readonly headers. There would be dozens of other ways to alter the query, and it would be pointless to try to enforce such a policy when you can just rely on simple but strong concepts that were proven to do the job.
    – Corneliux
    Commented May 15, 2014 at 8:56

Change "GUID" with a private key, generated at first browser launch/provided by user (or maybe domain-based), and a way to sign and identify client response.

This is exactly how secure shell (SSH) based auto-authentication works. But to make real you have to edit the browser to use a fixed or domain based private key, you add a login page where a successful login will upload the client's public key and it will have to be stored, and mod the HTTPS server to check the client identity against the one stored.

Note that this is very similar to actual HTTPS , you "just" have to add persistent client key and server side key<->session lookup.

This is actually called "Client-authenticated TLS handshake" but key exchange by classical login is out of standard.

Then your session is secured as long as private key is secured, but because already many browser give a way to store password in them, that should not be considered a big concern

You must log in to answer this question.

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