Session-Lock: Device-Token Binding in JavaScript

[zainazeem]

I put together a proof-of-concept library for device-token binding last year that's similar to this proposal in spirit (recently found this due to the announcement). It may or may not be ready for production use, but it can be implemented today and will work across all reasonably modern browsers, minus Firefox in private browsing mode. For better or worse, it does not need a TPM to work, so it should support most hardware. Server-side implementation should also be fairly quick and simple, or at least more so than the proposed DBSC flows. In addition to browser JS, the library includes functions to be used in Node.js servers to simplify validation.

Repo: https://github.com/zainazeem/session-lock
Writeup and demo: https://session-lock.keyri.com/

Flow

At login, the browser creates an ECDSA key pair with SubtleCrypto. The private CryptoKey is set to be "unextractable", and a reference to it is stored in IndexedDB. The public key is sent as part of the login request. The server adds this key to the payload of the JWT it returns to the browser. Whenever the browser wants to use the JWT, the library appends a timestamp to the JWT, generates a signature for this combined string, and appends the signature. The server then extracts the public key from the JWT and uses it to authenticate the JWT+timestamp, in addition to authenticating the JWT itself through the usual verification of its server signature. It also checks the timestamp to make sure it is recent enough to be within the server's recency threshold for preventing replay attacks. The CryptoKey reference may or may not be removed from IDB at logout.

Advantages

• Simple implementation: no new routes or network calls are needed
• Compatibility: works today on a wide variety of browsers and hardware
• Fast: <15ms latency observed on both browser and server
• Secure: protects against most token theft threats (should cover all those listed here: https://blog.google/threat-analysis-group/phishing-campaign-targets-youtube-creators-cookie-theft-malware/
• Straightforward refresh mechanism: the server can simply take the public key in the expiring JWT's payload and include it in the new one's

Drawbacks

1. The flow's reliance on a device timestamp is suboptimal. If the server's recency threshold is too low, a slow connection or a bogged-down server could result in an erroneous rejection. If it's too high, the risk of replay attacks is higher. In testing, it seems 2000ms is sufficient to support poor connections, and a replay attack in that window would be challenging. The server could also maintain a cache of used JWT+timestamp strings and reject duplicates that come in after the "original" to nullify this risk.
2. Lack of TPM utilization could lead to private key theft. It's unclear to me how difficult it would be to extract an "unextractable" CryptoKey. I think some browsers encrypt these keys and may even use a TPM to do so if available, but if a TPM is not involved at any step, it would theoretically be possible for sophisticated malware to eventually exfiltrate the private key.
3. A JS library approach is vulnerable to tampering. For example, malware could intercept the JS as it's being loaded, set the CryptoKey's extractable property to true, and pull it out.
4. Malware might be used to generate JWT+timestamp+clientSignature tokens. I understand that a server challenge mechanism would mitigate this, in exchange for greater implementation complexity and latency.

---

Overall, such a flow can already be implemented by individual applications with little effort to protect almost all of their user base against current token theft threats. These threats would have to become a fair bit more sophisticated in order to defeat this strategy. The strategy can also be implemented in native mobile apps, in which case it would take advantage of TPMs and reduce the tampering risk.

Hopefully this was helpful in some way. Feedback/questions are welcome, and I look forward to this project's development.

[arnar]

This looks great! All of the drawbacks you list are fixable with including server challenges and browsers implementing the key storage in malware resistant ways. You would just lose the low latency property for many users. But therein also lies a catch.

We did in fact experiment with something like this, as we were drawn to the simplicity. However we found even more complexity in how to retrofit this to existing webapps. To use your example: What does the server do when it inevitably receives a request with a timestamp that is too old? It needs to somehow signal back to the browser that it should regenerate a signature, and then retry the request. And generally when this happens, the browser has already sent multiple requests with the now expired token - so the browser-side mechanism here has to handle that.

The best we came up with, that didn't require new complex APIs, was to signal that failure and retries with 302 redirect responses. But these aren't designed to be idempotent retries, so apps (both client and server side) would have to deal with that some other way. In addition, to avoid flooding e.g. a TPM with multiple simultaneous requests when this happens, the handling of the 302s by the browser had to be somehow special anyways, in order to coordinate them.

In the end we ran aground with this, and that's why the somewhat strange new complexity in DBSC is there.

[jackevans43]

I guess my thought was to implement DBSC using JavaScript (based on some generic capabilities such as generating cookie values synchronously from a function, TPM API etc) rather than baking the entire functionality of DBSC into the browser. The downside is each webapp would need the DBSC library added to ensure the cookies/tokens were generated, but I don't think any existing code in app would need to change or be aware of it.

[kmonsen]

I think you could implement DBSC in JS assuming you had a TPM JS API and the whole app flow went through JS. That is a different problem than we are trying to solve.

[peterfritz]

DBSC appeals to me because it reduces the likelihood of errors by developers during implementation. When dealing with a multitude of APIs that developers should use to secure user sessions, there will invariably be a variety of implementations, some of which may be less than ideal. Furthermore, abandoned libraries become an additional concern. With DBSC, there should also be minimal or no client-side JavaScript. This translates to framework agnosticism and allows the browser to refresh the session even without the website being opened.

Afterwards, I think implementing more security-focused web APIs so developers can create their own implementations would be awesome. But having one incredibly solid way to stop session hijacking that's easy to implement and has awesome defaults is something that we badly need as soon as possible.

[JWally]

So this is probably a dumb question - so apologies in advance, but why not handle the JWT as its currently being handled today with the caveat that it has to have a valid ECDSA Signature?

The client could return the following headers:

Authorization: Bearer jwt
x-jwt-base64: base64 encoding of the jwt
x-jwt-signature: ecdsa signature of the base64 encoded jwt

If the signature fails, it gets 403'd; all other logic is handled as it is currently handled today.

[arianvp]

Service workers could implement the locking primitives we need here. Service Workers come with a waitUntil function that allows you to pause all incoming fetches until a promise resolves in the activate event. It almost has the semantics we have.

In the fetch event it only extends the lifetime of the service worker. But if we'd extend the semantics to delay other incoming fetches for the lifetime of a fetch event (which it currently doesn't do) then this would work:

let _sessionKey: CryptoKeyPair | null = null;
let _nonce: string | undefined = undefined;

async function generateSessionKey() {
    console.log("Generating new session key");
    _sessionKey = await crypto.subtle.generateKey("Ed25519", false, ["sign", "verify"]);
    await new Promise((resolve) => setTimeout(resolve, 30000));
    console.log("Generated new session key");
}
async function intercept(event: FetchEvent): Promise<Response> {
    const { request } = event;
    const headers = new Headers(request.headers);

    // Sign the request with session key
    _sessionKey && headers.set("DPoP", `DPoP ${await dpop(request, _sessionKey, _nonce)}`);
    const response = await fetch(request, { headers });

    if (response.status === 401) {
        // delay all other requests to make sure they get the new session key
        event.waitUntil(generateSessionKey());

        const dpopNonce = response.headers.get("DPoP-Nonce");
        if (dpopNonce) {
            _nonce = dpopNonce;
        }

        // Retry the request with the new session key
        const newHeaders = new Headers(request.headers);
        _sessionKey && newHeaders.set("DPoP", `DPoP ${await dpop(request, _sessionKey, _nonce)}`);
        const newRequest = new Request(request, { headers: newHeaders });
        const newResponse = await fetch(newRequest);
        return newResponse;
    }
    return response;
}

self.addEventListener("fetch", (event) => { event.respondWith(intercept(event)) });

[kmonsen]

Two things:

• I don't think SubtleCrypto is unexportable like a TPM key so you are sort of moving it to a different problem. In that case if you are small enough maybe it is good, but for a determined attacker I don't think this will work.
• Adding to Arnar's comment we had to require that challenges from one server were temporal stable for a few min to make sure we did not overload the TPM.

[danmarg]

Yeah, certainly you could just create an API like SubtleCrypto which specifically asks implementors to use TPM (or equivalent) storage.

This is more or less what we originally conceived of, as @arnar said above. "Just the basics" a la (and inspired by) WebCrypto but with TPM backing (and a purpose-built API just to ensure that).

I was originally a strong advocate of this approach, where the browser does less and more is done in the webapp, so I am very sympathetic to this argument. As Arnar said above, I don't think the problem is per se TPM access but rather a question of how best to get the complicated bits around state management (of the bearer token) working right, and whether it's better for every website to have to do it themselves (presumably many with shared libraries, of course) or for browsers to just do it correctly.

Aside from the difficulty argument Arnar alludes to above, I will also note that browsers can of course just be smarter in general about things web apps cannot know, such as:

• optimizing bearer token refreshes in anticipation of page loads (like when a user starts typing a URL into the nav bar)
• optimizing bearer token refreshes across origins to deconflict TPM usage

Of course, this is a bit similar to another discussion we had on this repo, about the limitations of TPMs. If TPMs were faster and higher throughput, you might not really care about those constraints, but, well, here we are.

[kmonsen]

We are considering a JS API for DBSC at some point in the future as well.

[wparad]

I would love to see the day that the browser allows users to register OAuth providers (or others) directly into their browser, and then calling navigate.login() in a webapp would abstract away which provider was actually being used and let the user fully decide. It also would solve the problem of real estate in the "login box" since all providers would technically fit (because you only need one button "Log in with Browser". But I would much prefer to see a full proposal for that feature done correctly, rather than some partial implementation looking only at the end of the flow looking only at sessions. But if that future that is coming, and everyone believes that this exact work, in this exact form will actually bring that reality closer, then I'm all for it. Right now, I'm not drawing the connection though :(

[arnar]

@wparad are you familiar with FedCM (MDN)? That at least has some partial ideas on the real estate problem (often called the "Nascar problem"). Abstracting from the RP's choice of an IdP is harder, because in general RPs need to make some trust decisions there.

There may very well be a future, and not even such a distant one, where OAuth sign-in and authorization plays nicely with DBSC, carrying device-bindings with the IdP/AS over to the relying party. But DBSC is definitely not trying to solve the authentication problem (except in that many of us, myself included, work on things like WebAuthn and FedCM as well)

[kmonsen]

I see DBSC as kind of orthogonal to signing in, and would think the way forward is to work with for example WebAuthn and FedCM for that since there is great progress happening there. We would prioritize interoperability with existing standards instead of inventing again what others have done.

[reitowo]

I would like to say that, after digging into source code of Chromium:

1. These 'non-extractable' attributes are only used for javascript. It doesn't create a non-extractable key on your security hardware.

2. When storing to Indexdb, it stores the whole private key by serialize v8 object, not a reference, not a handle to the hardware.

3. Nevertheless, this solution surely secured the credential unless your Indexdb file got stolen, which equals to the cookie file being stolen.