Hacker News new | ask | show | jobs
by xori 789 days ago
Rather than generating key data on the client in the open, and storing it in IDB, I would recommend the Credential Management API[0]. Hand off the responsibility to proper generation and storage to the user agent. Then do your signing of the JWT with them instead.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Credential_...
1 comments
jwally 789 days ago
I'll have to check that out, thanks!

If it can store live objects - its perfect.

IDB is neat because it can store a PrivateKey Object whose `extractable` attribute has been set to false. So when you try to see the crypto data, you cannot.

link
xori 789 days ago
When you `.get` a credential you can provide a challenge that it signs which you can make the JWT. With an added bonus that this passkey can exist on your phone or password manager which you can use to authenticate on a different device while still feeling confident in it's security.
link
jwally 789 days ago
TBH, I'm not an expert here.

What you're describing looks like webauthn which is used to verify the identity of a user by creating a private key on their HSM/TPM when the user signs up, and usually requires biometrics or a PIN iirc. This is used for future authentication events - which usually return a JWT.

This JWT that says "My name is Justin. I am logged in. I am an admin".

What I'm trying to solve for is "Make it so that the JWT doesn't work, except with the computer it was issued to".

In the setup I'm proposing, the JWT your server creates has your client's webcrypto Public Key in it (Naturally you verify it before putting it in there).

Now, whoever steals your JWT needs to be able to sign things with the private key that's locked on your browser - which is hard if you set it to inextractable.

link
unraveller 788 days ago
Sounds like you are trying to prevent replay attacks.

How do you imagine JWTs are being stolen in the first place though? XSS sneaky websites or someone over the shoulder.

Just seems that if the attacker is all up in your browser extensions can't they just inject email and password text elements into the dom and see what gets filled by the browser saved logins?

link
jwally 788 days ago
Its not so much replay attacks I'm trying to solve for here ( although putting the instantiating user's IP address in the JWT seems like it would do a lot to thwart that )

I think the main thing here is preventing anyone from using my JWT who isn't on my browser.

Even if I'm on a site that leaks data via xss, and have several plugins that broadcast my cookies, localstorage, etc - and my live JWT and refresh tokens make it into the hands of bad guys; its worthless in the setup I'm proposing - I think...

link