I’ve noticed this warning
in phoenix, and wondered what kind of vulnerability would storing a “forever valid” session id have. In other words, is this warning only for the users who store some extra data in the token (besides the session id) which can go stale?
Besically the idea of it is if someone gets their hands on a token without an expire that does not belong to them they will forever have access with that token. With an expire time that is not the case. Depending what you are using Phoenix token for it could be perfectly fine that way though.
I believe the purpose of this warning is to encourage people to explicitly opt-in to non-expiring tokens by setting max_age to :infinity. The future default will ‘err on the side of caution’, which is a good security practice.
One use-case for non-expiring tokens is to simplify development/testing. In a production environment, non-expiring tokens should only really be used if the token can be revoked, e.g. on sign-out or when the user changes password. This can be achieved by encoding in the token a timestamp or sequence number that is also stored in the User DB record, and updating the DB on sign-out or password change, rendering old tokens invalid.
Without revocation, every sign-in would issue yet another valid token, and the user would have no control over who might abuse such old tokens. A token might be left behind on a public computer, or yet-to-be-discovered weaknesses in crypto protocols might allow an attacker to extract a token from an old packet capture. There would be nothing the user could do, and the site admin could only change the secret key, invalidating all tokens at once.
Besically the idea of it is if someone gets their hands on a token
In my case the token is stored in the secure enclave and sent to the backend over TLS so that is hardly the case.
without an expire that does not belong to them they will forever have access with that token. With an expire time that is not the case.
I don’t see much difference between forever and at least some time: in both cases the system is breached and the damage is done.
I believe the purpose of this warning is to encourage people to explicitly opt-in to non-expiring tokens by setting max_age to :infinity. The future default will ‘err on the side of caution’, which is a good security practice.
What I don’t understand, is why should there be a default for everyone, even if, as in my case, there isn’t any real additional threat for having “forever valid” signed session ids …
In a production environment, non-expiring tokens should only really be used if the token can be revoked, e.g. on sign-out or when the user changes password.
In my case the users don’t have passwords, their “accounts” are tied in to their installation of the app (iCloudID). I only need to know their account or user id, which is, again, exchanged with the server over TLS and the token itself is stored in the secure enclave.
Without revocation, every sign-in would issue yet another valid token, and the user would have no control over who might abuse such old tokens.
That might affect me, but I’m not sure how. Currently, only one installation of the app per account is allowed, but in the future I might change that. But even then I don’t see why I would want to revoke a token with session id, for someone to abuse it, the abuser would have to have direct access to the victim’s phone.
or yet-to-be-discovered weaknesses in crypto protocols might allow an attacker to extract a token from an old packet capture.
This definitely could affect me. But that would affect every user, so I might as well just change the secret used for signing the tokens.
Thank you, @voltone!
If your use-case and threat model allow never-expiring tokens, you can opt-in by passing :infinity. That will eliminate the warning. The upcoming change and the warning are about making this opt-in rather than opt-out, to avoid mistakes due to someone missing a warning in the docs.
There are other, perhaps more likely, examples where the protection of TLS might be less than perfect. For example, in the past CAs have been compromised and fake certificates issued to intercept communications. This might only affect users in a certain country or using a certain ISP.
The point is, relying on tokens that can never ever be revoked is a risk, no matter how hard you try to protect them. Giving users an option to revoke their own tokens using the DB-backed mechanism I described might be wise, to add another layer of protection.
I intend to “solve” it with certificate pinning. Since it’s an iphone app that I’m developing, it is possible to do.
But I do understand that there is most likely a way to abuse every “forever valid” token, I just wanted to be sure and know what the possible threats are.
Giving users an option to revoke their own tokens using the DB-backed mechanism I described might be wise, to add another layer of protection.
I’ll probably add a counter together with user id into the token, and increase the counter once the user decides to refresh the token. But I’m not sure I want to add automatic expiration via timestamps.
© Copyright Elixir Forum | Terms | Privacy & Cookies
