For a more comprehensive writeup and quick demo, you can visit the link. In short, the library adds a device-bound signature to the session token each time it’s used. At login, it creates a signing key pair on the browser using SubtleCrypto, with the private key set as “unextractable” and stored in IndexedDB (this forms the basis of its device-binding). Also at login, the public key is sent to the server along with the user’s credentials. If the credentials are valid, the server adds the public key to the payload of the JWT it returns to the client. When the client uses the JWT to access a protected resource, session-lock adds a signature to the end of it, along with a timestamp to mitigate replay attack risk. The server then validates the signature using the public key embedded in the JWT. The private key must be removed from IndexedDB upon logout.
While Chrome’s DBSC would be a nice solution when it gets around to being deployed in Chrome and Edge, I think session-lock would help a lot today across all browsers in countering common attacks like malicious browser extensions that rip LocalStorage and cookies. Also, implementing the general flow in native mobile apps[3] would have the same key advantages as DBSC - compiled code already on the device and utilization of hardware TPMs.
Aside from JS tampering and extracting “unextractable” CryptoKeys from IndexedDB, please let me know if you can think of any other potential attacks. Happy to answer any questions.
[1] https://blog.chromium.org/2024/04/fighting-cookie-theft-usin... [2] Other than Firefox private browsing mode due to its blocking of IndexedDB [3] Using CryptoKit / KeyStore for ECDSA