You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I really like many aspects of how django-rest-knox is implemented, and how configurable it is.
The one thing I really wish I could get perfect is,
I would like to have tokens expire after a relatively short time, e.g. 15 minutes, but with auto-refresh on use.
I would like to have a maximum lifetime of a token -- no matter how many times it is refreshed, it expires anyways after e.g. 24 hours from when it was first issued.
My reasoning is, if I turn off token refresh entirely, then the token timer needs to be at least two hours for it not to be annoying to users of my site, so that they don't have to type their password again and again.
But having tokens expire automatically after 15 minutes of non-use is quite good for security. This is also touted as a benefit of Oauth's two-tiered token system, where the shortest-lived token expires quite quickly. It also reduces the harm if users don't click the "sign out" button actively when they leave the site, since whatever credential they have is going to go away if not used within 15 minutes. (By contrast, Knox only has one token class, which is a lot simpler and this seems like a big win for sites that don't need full federated Oauth.)
The problem is that, if I use this auto refresh feature (also called "sliding tokens") and an attacker does steal a token, as I understand, they can refresh it indefinitely, as long as they make some request with it every 15 minutes (for example). So that escalates theft of a single token, which ideally would be valid at most 24 hours, into a permanent break, where the attacker potentially has access to this user's account forever.
There are things that I could do to mitigate that, like, rotating the django-secret-key on a 24-48 hour basis or something like this. But that has a lot of other consequences, for example it may cause the challenges in password reset and invite emails to rotate prematurely, since they are also derived from the django-secret-key.
Would you be interested in a patch that allows me to turn on auto-refresh with a short token lifetime, but have a second maximum lifetime, which if exceeded, disallows token refresh and forces the user to log back in again with their password?
The text was updated successfully, but these errors were encountered:
I perfectly agree with you... I am currently on a project and if this update is done my life would literally be so much better. As it stands now I am planning on automatically deleting all tokens on the front end at a set time each day to force a new log in..
Hi,
I really like many aspects of how django-rest-knox is implemented, and how configurable it is.
The one thing I really wish I could get perfect is,
My reasoning is, if I turn off token refresh entirely, then the token timer needs to be at least two hours for it not to be annoying to users of my site, so that they don't have to type their password again and again.
But having tokens expire automatically after 15 minutes of non-use is quite good for security. This is also touted as a benefit of Oauth's two-tiered token system, where the shortest-lived token expires quite quickly. It also reduces the harm if users don't click the "sign out" button actively when they leave the site, since whatever credential they have is going to go away if not used within 15 minutes. (By contrast, Knox only has one token class, which is a lot simpler and this seems like a big win for sites that don't need full federated Oauth.)
The problem is that, if I use this auto refresh feature (also called "sliding tokens") and an attacker does steal a token, as I understand, they can refresh it indefinitely, as long as they make some request with it every 15 minutes (for example). So that escalates theft of a single token, which ideally would be valid at most 24 hours, into a permanent break, where the attacker potentially has access to this user's account forever.
There are things that I could do to mitigate that, like, rotating the django-secret-key on a 24-48 hour basis or something like this. But that has a lot of other consequences, for example it may cause the challenges in password reset and invite emails to rotate prematurely, since they are also derived from the django-secret-key.
Would you be interested in a patch that allows me to turn on auto-refresh with a short token lifetime, but have a second maximum lifetime, which if exceeded, disallows token refresh and forces the user to log back in again with their password?
The text was updated successfully, but these errors were encountered: