Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevention against replay attacks #36

Closed
hybrisCole opened this issue Dec 3, 2014 · 4 comments
Closed

Prevention against replay attacks #36

hybrisCole opened this issue Dec 3, 2014 · 4 comments

Comments

@hybrisCole
Copy link

Hello,

So this is the workflow I have at this moment for using JWT:

  • User logs in, sends usr/pwd.
  • Node validates it against an old .NET DB, if the usr/pwd matches, I issue a JWT with 5min expiration and send it back to client.
  • I store the token using mozilla's localforage.
  • Everytime I do a new request, I invalidate the current token (adding it to a blacklist), and add issue a new token in response.

So far so good, everything works like a charm, but I have a reaaaaally big concern... what happens if someone grabs that token that I have saved on localstorage? and then creates the same request trhu, let's say, POSTMAN? That's going to:

  • Invalidate my token and kick me out of the session where I'm using the current token (already blacklisted because it was used by the evil genious with POSTMAN)
  • Return new tokens to evil genious.

So how possible is that someone is able to hack my localstorage/indexedDB/WebSQL?
Are my steps wrong?
What's the right way to implement a "nonce"? (I think I don't need this since I'm doing like a heartbeat, everytime I do a request with my token, I return a new one and the previous one gets blacklisted)

Thanks in advance

@hybrisCole hybrisCole changed the title Prevention against replay Prevention against replay attacks Dec 3, 2014
@dschenkelman
Copy link
Member

Hey Alberto,

The JWT spec provides the jti field as a way to prevent replay attacks. That being said tokens return by Auth0 currently (we are thinking abut adding it in the future) don't return a jti, but basically you would just blacklist the jti to prevent a token being used more than X times (X being 1 in your case). You are kind of implementing a nonce (think of the token's signature as the nonce).

Nevertheless, in general you don't get stuff from local storage everyday (but it is possible of course). For example a XSS attack against your site would be able to retrieve credentials from local storage.

There are two alternatives that you could use to avoid someone having infinite tokens if they steal one:

  1. Set a lot expiration for tokens.
  2. Provide a way to blacklist tokens that have not been used (even perhaps a user).

If a token gets stolen you blacklist it (or the nth token that has been issued after it) and wait for it to expire. Once it does, the attacker won't be able to impersonate the user any more.

@hybrisCole
Copy link
Author

Thanks @dschenkelman, I'll try to handle this in that direction (blacklist tokens and try to make my site XSS proof), if you have any literature I can look into, it would be very helpful 👍

@dschenkelman
Copy link
Member

Great. Glad we were let to help.

Just FYI, this kind of question could be useful for others, so you could post at ask.auth0.com

@chadfurman
Copy link

Super old thread, but in case someone else hops along here, SameOrigin HTTP-Only cookies over HSTS / HTTPS are useful when working with an API on the same domain

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants