It’s also very common that a website wants credentials to be cleared when the user is inactive for a certain amount of time. This is important for sensitive applications such as banking and healthcare. Currently there’s no way to enforce that a cookie is cleared on device lock or user inactivity, especially because security requires that such cookies not be visible to JavaScript. A native session management solution should be able to request that the browser clear a session in the case of device lock, the user navigating away, etc.
No, the correct way to do this is to use the cookie to store an opaque session identifier generated at each login, then expire the session data on the server sometime after its last touch. This solves both forcing expiration and the copying/hijacking of cookie values from long-saved browser state.
The proposal says that server-side expiration is still required. The ability to request that the client delete the token when the computer is locked is purely additive; if the client does not honor it, at worst you just get something equivalent to the status quo with cookies.
If the client works correctly, you get a security feature that is currently impossible with cookies (wiping the session as soon as the laptop lid closes, instead of some time after that.)
I agree that WebSession would benefit from a time since last touched expiration, although I'll point out that a time-based approach doesn't handle the "when device is locked" requirement.
I've noticed reddit doesn't invalidate your cookies even if you click the logout button. There is a button in the site settings under your list of sessions, but I haven't tested that.
I noticed it because I delete site cookies often, and paste them in from a file whenever I want to comment. Occasionally click "logout" without thinking. Got creeped out by that year-in-review thing they do once.
> Because WebSession is dedicated to session maintenance and nothing else, a client could theoretically reject all cookies on any supporting site, ideally skipping the jarring cookie banner experience.
This has nothing to do with cookies, the banner is required if the site is processing data that is not just technically necessary. In this case the site needs to ask the user for consent or at least inform them of processing due to legitimate interests.
Very unlikely this will cause anybody to be fired. Will not probably even lead to company fines, nor the disappearance of the illegal dark patterns. E.g. a lot of sites used the IAB nag that was found illegal by the regulators. But IIUC only IAB had to pay a small fine and I'm quite sure nobody got fired for it because it was the "industry standard".
NOYB is fighting the good fight, and without it GDPR would be even more useless. But it's a losing battle, and NYOB itself is sort of admitting that. https://noyb.eu/en/statement-4-years-gdpr
GDPR is in theory a good law (although things like mandatory honoring of do-not-track headers should have been obviously included). But it's not being enforced almost at all probably due to regulatory agencies and EU being corrupt AF.
Having a lot of money, lobbyists and lawyers makes you immune to the law.
> Will not probably even lead to company fines, nor the disappearance of the illegal dark patterns.
NOYB’s intervention has lead to fines and I’ve been seeing way more banners have a “Reject All” at the top level. I remember noticing that at the same time NOYB posted about it. Unfortunately I don’t remember any useful keyword to search their website and post the source.
Though I’m not disagreeing with you. I have no doubt the dark patterns will continue and these companies will be as vampiric as they can get away with.
My strategy is to use that as a useful signal: the more a company or website bends over backwards to try to get me to accept data collection, the more I know I can’t trust them and will simply leave.
Do you have a reference for the fines? Can't find much on the enforcement tracker [1], but seeing if the decision is about a nag or not is not easy to see quickly, so I may have missed them. NOYB also gave them a "grace period" before filing complaints, so I don't know how many complaints they actually made.
A lot of the nags have indeed gotten less illegal lately. Although I have very little faith in that even clicking Reject All really prevents tracking and selling me out. There are still those "legitimate interests" etc loopholes. And probably no regulator actually checks that the Reject is honored at all. Nowadays I don't even care. Used to go private mode for those but don't bother anymore. Hopefully at least my aggressive ad blocking makes spying on me mostly worthless on them.
Implementation of the GDPR consent was broken from the getgo (likely due to corruption). The spirit of the law is clearly that people shouldn't be tracked if they don't want it. Vast majority don't want to be tracked but vast majority are tracked.
If EU would have actually wanted this to work it would have been something like DNT. Also the promised megafines have not (and will not be) materialized and the (widespread and blantant) violations are at best just cost of doing business.
But making an actually effective implementation would have closed many revolving doors and fancy dinners.
Sorry for being so negative on this but I think entertaining hopes for such a fundamentally broken system may prevent less broken ones from arising.
https://www.enforcementtracker.com/ (going through the cases also shows that the DPAs are mostly fiddling with small fish who don't have the corruption power and/or lawyer army)
For Spotify and Tele2 at least these are cost-of-doing business fines. The GDPR can fine up to 4% of revenue. Spotify's revenue is about €17 billion, so the fine is about 0.03%. For Tele2 the fine amounts to 0.05%.
Grindr did get almost 3%, so that would be at the megafines level. Wonder how much they gained by selling the data though.
In comparison, I'd get easily fined over 3% of my yearly wage for shoplifting here in Finland. And of course would lose whatever I lifted. For Grindr-level privacy crimes I'd probably get a prison sentence. If you want to break the law, better make it for shareholder profit.
> NOYB is fighting the good fight, and without it GDPR would be even more useless. But it's a losing battle, and NYOB itself is sort of admitting that. https://noyb.eu/en/statement-4-years-gdpr
I'm not sure how much of this is attributable to NOYB, but over the last year or two, years there's been a significant uptick in the number of "Reject All" buttons showing up and I have a hard time believing companies are putting those there out of goodwill.
> GDPR is in theory a good law (although things like mandatory honoring of do-not-track headers should have been obviously included). But it's not being enforced almost at all probably due to regulatory agencies and EU being corrupt AF.
Agree with the missed opportunity of DNT headers being included in the law, but enforcing EU rules is always tricky. At the end of the day, it's 27 different countries, each with conflicting interests. With GDPR in particular, I believe one of the issues is that it's enforced in the country of incorporation, so another country can hold up the enforcement process if their data protection agency is slow, no matter whether due to corruption or incompetence.
When it comes to things that (big) business doesn't like - e.g. GDPR, tax evasion, antitrust, consumer rights, rule of law - enforcement is somehow always so so difficult. And when it comes to stuff like enforcing copyrights, patents, trade agreements and forced privatizations the enforcement works fine and dandy. GDPR enforcement was designed like it is and it was well known that it will be like this.
My take is that the corruption is not only a national matter, like europhiliacs and the EU's huge PR-propaganda machinery like to explain it. EU was set up as an antidemocratic organization for business interests and seems to remain so. The endless lobbying billions work.
> I'm not sure how much of this is attributable to NOYB, but over the last year or two, years there's been a significant uptick in the number of "Reject All" buttons
That’s ironic because cookie banner feels soaked in deception. They should be called tracker banners instead of sugar coating it by calling it a cookie also the ask to try and extract data to be sold on a side market. Everytime I see a cookie banner I think I am not only a client but also a potential product and that makes me think less of the brand. Also it makes the site look ugly and cluttered.
You’d think you’d try to avoid the above of you had the option.
I recall a friend of mine worked support for some sass meeting software (oncehub-like) and got an email from a non-technical user asking if the booking invite page is missing a cookie notice.
He had to explain that they re-engineered the page a while back to not collect any data besides what the person puts into the form (the page explains that collection, but inline) so they wouldn't need one. Don't know if it was an aesthetic choice or if they AB tested it.
IANAl, but this would still be compliant if they use legitimate interest as a justification. In that case the user just needs to be informed and have the opinion to object via separate means.
Yeah, companies tend to be over-careful. They trust the legal department knows what they're talking about but in this case they don't, but the company decides to listen to them anyway. Especially if the legal department is a part of a US company, thinking they adhere to some EU regulation they can't seem to quite understand fully.
I’m loving all the feedback and wanted to address some things:
* Yes, nonce tracking is expensive. HTTP request signatures could be used instead of nonces—they’re just not fully fleshed out yet, from what I can tell. And a lot of other crypto systems we rely on in Web traffic today also assume proper nonce tracking. Fortunately you only need to track distinct nonces per established session, so you could wait to allocate storage for them until the client actually tries to set up a WebSession, and use a Bloom filter to save on storage at the risk of some false positives for nonce reuse (could be risky if you’re relying on that as tamper evidence, but you could tune your filters accordingly).
* The stuff about the ergonomics of cookies and banners and auto-log-out as they currently are is mostly incidental. I’m just trying to paint a picture of how tighter integration of the notion of a ‘session’ into the browser itself could improve the UX we currently have today.
* Many people have pointed out that this is not stateless. Indeed! This is supposed to be a more secure way of establishing a stateful connection over a stateless protocol, for which there is already a demand which we’re meeting with the least secure possible method (bearer tokens sent in plaintext over the channel). Issues with scalability need to be addressed on the implementation side, but I believe the protocol is still sound and not inherently unscalable (no more than TLS in its current form).
I am going to look for opportunities to fold these points into the document itself, and maybe rearrange some of it so that these points get covered earlier and more clearly.
On the nonce-tracking front, what about a monotonic counter?
The client can generate the next nonce by incrementing the previous nonce value.
The server only needs to remember the highest nonce it's ever seen, for a particular session, and reject any new nonces less than or equal to it. O(1) in time and space, and no need for anything clever like bloom filters.
Edit: One issue I can see with this approach would be, what if requests arrive (or are processed) out-of-order? You'd perhaps want to track a small window of nonces to account for this.
> You'd perhaps want to track a small window of nonces to account for this.
Just send a signed UTC timestamp instead of a nonce. Make it valid for like 5–15 seconds to ensure it doesn't break if clocks are out of sync slightly – it will still be better than cookies that live practically forever.
You cite trivial issues such as setting flags on a cookie, then go on to require checking nonces for uniqueness. You know what most people would do? They would ignore the expensive nonce check.
This would turn this into an expensive client generated opeque token. How would you handle sites setup with sub domains?
Reading between the lines, it sounds like you want a alternative session method so legislation can force disallowing all cookies and tracking, or blanket ignoring them client side.
I found Big Cookie. I mean seriously sitting in-front of you is a proposal that’s objectively better than session tokens in a cookie jar, where the nonce portion could be entirely optional at the expense of allowing replay attacks, and you call it a non starter. You’re just looking for reasons to not be secure at this point.
Trying again to be more constructive, rather than having a nonce, make the nonce meaningful, so there is a time component, such as seconds from initiating the session, and a validation portion that shows this came from the session function and attests the time portion is valid.
Then nonce storage, if you do it, can be limited to window when it is valid.
The only thing in this protocol that prevents the reuse of Authorization header is keeping track of nonce:
> Validating that the nonce has not been used already for this session. Important: at this point, the nonce should be added to the ‘seen’ set, because nonces should be invalidated whether the signature validation passes or fails. Failure to do so can allow attackers to brute-force a valid signature for a single nonce.
That's one extra db row / kv pair for every single request, including read requests, for very little benefit.
Request signatures incorporating timestamp and optionally path/payload are stronger, can be statelessly validated, and are already in use today on certain sites.
A Bloom or cuckoo filter would allow for efficient tracking of nonces (depending if the security model prefers false positives with 4xx/resend, or false negatives)
Yeah I think the proposal should add some optional binding of the web session to http resource semantics.
Also re nonces if you only keep track of active nonces and have the server return a next-nonce, or use a counter like TLS, then you avoid the ugly need to keep track of seen nonces and only need to remember currently active nonces.
Timestamps can be vulnerable to clock attacks, right? Why not just include a monotonically increasing request number along with the nonce in each request?
What clock attack? You validate the timestamp on the server and reject if the timestamp is too far off. The same request being repeatable within say 30s isn’t a problem in 99% of cases.
I'm referring to threat models where the attacker might be able to manipulate time on the server, either directly or through NTP servers, etc. Personally it's not something I would worry about but I've heard it discussed and was wondering how big a concern it is.
>> Timestamps can be vulnerable to clock attacks, right? Why not just include a monotonically increasing request number along with the nonce in each request?
> That interferes with the ability to send multiple requests in-flight at the same time.
I.e. it was assumed there was a sequence number, and I refuted that it disallows concurrent requests.
> As a result of increasingly strict privacy laws across the world, users are now beset with cookie banners across the Web
In the words of a law prof from the Radboud University, more accurate is to say "as a result of an entire industry colluding to undermine legislation".
Seems like more companies than needed are confessing to misusing people's data. If you only use cookies for login or other essential information (not related to tracking people), you do not need to show any cookie banner. Same with the GDPR stuff, if you don't store more data about users than absolutely needed for essential functionality, GDPR isn't affecting you.
>if you don't store more data about users than absolutely needed for essential functionality, GDPR isn't affecting you.
Except you need to completely delete all data for users who close their account. Need to have a data protection officer, and need to have a way to give users all the data you have from them upon request. All of which can be a significant burden for small companies, or non-commercial websites.
> Except you need to completely delete all data for users who close their account. Need to have a data protection officer, and need to have a way to give users all the data you have from them upon request. All of which can be a significant burden for small companies, or non-commercial websites.
Well, you're a good example about people misunderstanding GDPR :)
If you're a small company and processing data isn't a core part of your business and whatever the business does doesn't create risks for your users, there are parts of GDPR you don't have to care about, for example you don't need to have a DPO in that case.
GDPR is meant to protect users from businesses that are harvesting users data, in order to gain a bit of privacy back. It's not for your tiny SaaS that only requires a email to use and you collect no analytics about users.
The EP were just dumb. They let themselves be swayed by industry lobbyists to weaken the regulation and allow the cookiewalls. Now the EU gets blamed for this mess.
What they should have done is raise the "Do Not Track" flag to legal status. If the flag is enabled it must be obeyed without any further questions to the end-users. Making it mandatory would have solved the problem with this flag which was that everyone simply ignored it and it only added an extra bit of entropy for fingerprinting.
If this flag had become mandatory, the browsers that have removed it would have brought it back immediately because it actually would have become functional. Also, the onus would have been on the advertisers to stop friction for those who don't mind to be tracked. Instead of tricking people with cookiewalls the focus would have been on making the "tracked" experience as frictionless as the flag itself is.
But I guess the industry lobbied very heavily for this flag not to become mandatory because it would have instantly cut their tracking to near-zero and therefore remove the raison d'etre of many of these adtech businesses. It would have shocked the industry more than Apple's ID thing did to facebook. No big deal though IMO because this industry is undesirable and it would have triggered some real innovation in context-driven ads that are not privacy invasive.
It would have been the only good option though for the citizens. What the EU has done has only backfired on itself with everyone including the lobbyists blaming them for the cookiewall mess.
The only real advantage I see here is having a dedicated storage for session identifiers as opposed to clubbing it with other non-essential cookies.
Everything else in the proposal isn't really required.
Considering this, simply choosing a standard name for session cookies suffices.
Browsers can give an option to the user to rejects all cookies that don't have the name "WebSession". This is already achievable using extensions like uMatrix.
The instant you implement that, then everyone will just start squeezing all the tracking information they need into the WebSession cookie. Plus, this isn't backwards compatible with all the existing servers that use custom names for the session cookie. PHPSESSID, session_id, etc.
It's already unique, so no need to cram more information.
About the backwards compatibility - the whole idea suggested in the article is that the user can block all cookies and use WebSession. That isn't backwards compatible with PHPSESSID either.
I’d like to understand the threat model under which this is supposed to be superior to a bearer token stored in a heavily restricted (__Host- prefixed, Secure, HttpOnly, SameSite=Lax) cookie. Neither can be exfiltrated by JavaScript so they’re in pretty much the same spot as far as XSS is concerned. Both can be captured if the user agent is compromised so there’s no difference there AFAICT. Is interception of traffic or errant logging really a big source of compromised bearer tokens?
> It’s also very common that a website wants credentials to be cleared when the user is inactive for a certain amount of time. This is important for sensitive applications such as banking and healthcare. Currently there’s no way to enforce that a cookie is cleared on device lock or user inactivity, especially because security requires that such cookies not be visible to JavaScript. A native session management solution should be able to request that the browser clear a session in the case of device lock, the user navigating away, etc.
Ah, here's the evil part. If I don't want my browser to log me out of my bank's website when I lock my screen, my bank shouldn't be able to make it do so anyway.
DPoP[1] is on its way and already starting to see adoption by identity providers like Okta[2] (oh, the comedy). It's unfortunately specific to OAuth, so narrower in terms of application, but will cover how most web apps work today.
I see this as a complementary form of DPoP for first-party browser sessions. I took a lot of inspiration from DPoP, with the main novel construction being HMAC signatures over an interactively-negotiated shared secret vs. new elliptic curve signatures for every request.
I feel like nonce-tracking on the server side makes it a non-viable solution for a lot if not most of applications. A nonce needs to be stored/validated on every request, even a GET one. Seems like a recipe for DDoS.
I don't get why WebSession proposes to use authentication headers like WWW-Authenticate, when it calls out at the start that it's not a replacement for authentication protocols. If that's the case, surely it should just be using it's own headers to avoid confusion.
This seems like a great way to pull out session identity from cookies and sidestep a lot of the baggage there.
I would caution framing it as a secure replacement for cookies, it’s a secure replacement for session ID token cookies. Tons of cookies aren’t just opaque IDs.
>>>If someone steals this cookie, they can impersonate you.
Right; but with WebSession, if someone steals the client keypair (and generated shared secret), they can impersonate you just as easily. Why would this be any more secure against that?
Cookies aren't perfect, for sure, but I don't think this solves it.
You can steal a bearer token just by observing the request. You can’t steal a private key by observing a signed request. With a WebSession the attacker has to pwn your machine instead of your DNS.
Has to pwn your DNS and SSL, you mean. If someone has broken that, they'll get my credentials when I have to login at some point.
This seems to help mostly against servers improperly using cookies, servers improperly logging request content, and users improperly uploading HAR files that include bearer token.
And anyone who does those things improperly will also implement WebSession improperly - like not bothering to keep track of nonces - so what does it really gain us?
edit: just broadly on "pwn your machine vs pwn your DNS" - overall, in the general case, machines are much much easier to pwn.
Yes, but this presumably still runs on top of DNS and SSL and an attacker can exfiltrate a bearer token all the same if they pwn your machine. What this does is make the only viable attack vector the one where they're on your machine or getting you to unwittingly run stuff on their behalf on your machine.
Not going to comment on the technical merits of this proposal because it's not my area of expertise but as a user I look at any proposal in this space with extreme caution (because most of the time "the man" really is out to "get you" - see "Web Environment Integrity").
I'm a big fan of Firefox's Total Cookie Protection and make extensive use of the "Temporary Containers" extension, so I will likely disable this feature as well if it becomes standard because it eventually boils down to making tracking easier.
This would be more akin to being logged in to a specific site with a JWT than to tracking writ large. Basically, if your site has access to this secure key, then it already knows who you are (i.e. because you are logged in). This key would never be shared with third-party sites and doesn’t introduce any novel ways of doing so. You could clear the token by clearing website storage or disabling JavaScript.
From my reading of the article, WebSessions specifically doesn't do tracking. It's a replacement only for session cookies, not for tracking cookies. So with WebSessions for session maintenance, you can turn of cookies completely, if you want to avoid tracking.
It looks pretty reasonable to me (except possibly the nonce-management bit). I can't be bothered to try and pick it apart, and anyway I'm no expert.
A proposal like this will never fully replace cookies: quite apart from inertia and largely-unmaintained systems, it’s much, much more complicated for servers to implement. Diffie-Hellman, CBOR, encryption, session nonces… now compare that to just generating a big random string and using that as a cookie value and as the session table primary key. The consequence is that—even if there’s a nice backwards-compatibility path and all the browsers implement the whole lot—major frameworks like Django or Ruby on Rails will implement it, but smaller things and roll-your-own things won’t, because they’ve already got something easier that works about as well.
Just clear all cookies after the session. That's what I do, I just need to make a couple of exceptions for the few webpages I want to remember me across multiple sessions.
The extension CookieAutodelete makes it fairly painless, though you do need to remember configuring it for the webpages you actually want to stay logged in to (which may be fewer than you'd expect).
1. If you want the protocol to be “stateless” (once the session is established, that is), use a fixed, or allow any, nonce.
1.5: The proposed nonce tracking scheme is naïve but it’s pretty easy to devise alternatives and provide options (store active instead of expired nonces, nonce pool, or counter as nonce) depending on your threat model and security requirements. And sometimes naïve is all you need: if your nonces are session scoped and sessions are short (a session could be entirely ephemeral never hitting anything beyond Redis) then why not keep track of a few hundred nonces.
2. The point of this over cookies is that it is purpose built for maintaining sessions and secure by default. I’d love to turn off all cookies some day and have good sites still work normally.
3. The DH gives you asymmetric crypto meaning session token is never sent over the wire so it improves on the fundamental idea of a session in tue first place. It’s more than just a special cookie jar called websession with sane defaults.
I know this is a replacement for cookie, but some web apps use JS and sessionStorage on browser to store session token instead of using cookie.
This protocol seems to also depend on JS to do client side cryto logic and adding HTTP headers. Unless by browser/client it means the actual browser, which would take ages to get implemented across all user agents. In which case, it would likely be polyfilled by JS first as the de facto standard of doing things.
I wonder how this compares to using sessionStorage.
It doesn't mention any dependency on JS, there's pseudocode in Python to demonstrate generating/using the token.
> but some web apps use JS and sessionStorage on browser to store session token instead of using cookie
This is particularly strange, I've seen that frontend apps do this but I can't understand why because it's error prone and excellent attack vector. It boils down to emulating cookies, having to have some sort of request interceptor that includes the token on every XHR/fetch to serverside and another interceptor that saves updated token on every valid response from serverside. It seems like a misguided attempt to rectify problems that stem from CORS handling or shortsighted design where auth was bolted on as an afterthought.
There are valid use cases and complex interactions between multiple systems where the only solution is client handling of user token.
Also, sessionStorage is a web standard and it is designed to store data to be used in the session. If you think frontend devs shouldn't use it because they are incompetent at handling XSS, then maybe backend devs should also not use databases because they might leave the port open to public internet.
The protocol does provide for fallback: if the client doesn’t understand the WWW-Authenticate: WebSession header, it can just choose to ignore it and send a request without Authorization, at which point the server can fall back to a traditional session mechanism.
New tech will not magically make developers security conscious.
We'll just make (different) silly mistakes with the new tech.
Instead of reinventing the wheel, why don't we just gradually improve the defaults for cookies in browsers and educate developers on using the tech we already have with security consciousness?
> Even with all of these, a compromised client, an unsecured application log, or an eavesdropper on the connection after TLS termination could result in a cookie being stolen.
So it can be stolen from the client or the server. Same applies to this proposal.
Seems like a good proposal to me. Maybe there are privacy/security holes?
Is it sort of like a "rich mans" CSRF token, but you don't need to put it in the form, and it works on all requests GET, POST, ..., and is cryptographically secure etc.
TL;DR: A web-browser-based, non-JS-exposed, request authentication scheme using signed requests.
I see some problems:
1) This is a stateful protocol: Bearer-tokens are popular despite their insecurity because they allow remote-services to be entirely stateless (and thus, scalable), but this approach requires the remote-service to maintain a database of current private sesion ids ("Looking up the corresponding Spriv for the session;") and storing the nonce of every request made ("while also checking to make sure that nonce has not been used before."). This will not scale (and could even be a way to DDoS a server by hammering it with requests from distinct sessions).
2) The requirement of a handshake: which means the first HTTP request a browser makes can't be pre-authenticated, which makes for a suboptimal user-experience.
3) Good luck getting browser-vendors to all buy-in to this; I'm sure Mozilla will be happy to accept a PR, but the other players (Google, Microsoft, and Apple) will all have their reasons to drag their feet on this, and that's assuming it's even in their interests to support this (e.g. look at how Google tried to kill Apple's Storage Access API).
4) The hard requirement for a browser-based UI restricts the kinds of session activities you can support, e.g. consider how larger-scale web-applications don't have simple, single-user sessions, but will support things like impersonation, delegation, multi-tenancy and tenant partitions - this can't be reconciled with how browser-vendors will only want to display (at most) a simple yes/no prompt or a list of known sessions.
When it comes to new browser-based security protocols, it's a triangle problem: Replay protection, Statelessness, No handshake requirement: pick any 2.
----
Request-signing can work, obviously we can't rely on whole-request signatures (because the body-length is unbounded and can be streaming); but using a time-based nonce with a remote-service-provided preshared key (which can be derived from the existing underlying TLS session without needing a HTTP handshake). ...but what value does this add when cookies+TLS already work fine for this purpose? Thus, this is why nothing changes in this area.
I'd very much rather see a "Cookies 2.0" ("WebCookies" to use the current nomenclature) that provides a way for a declared JS (just like with ServiceWorkers today) to run with privileged access to the user's cookie store (thus side-stepping XSS/script-injection problems; the "trusted JS" could be declared via a HTTP header) as well as (yet another) cookie flag, but this time to designate cookie-expiration-due-to-local-user-inactivity. Oh, and a proper DOM API for cookies like we have with localStorage, and not the horrible stringly-typed `document.cookies` property. I don't understand why no-one has seen fit to add simple `add(key,value)` and `get(key)` functions to it. Argh.
No, the correct way to do this is to use the cookie to store an opaque session identifier generated at each login, then expire the session data on the server sometime after its last touch. This solves both forcing expiration and the copying/hijacking of cookie values from long-saved browser state.