While I agree that the tokens must be expired on logout, it's hard to gain access to the token via MITM because the API requests are performed over TLS [0]! This point seems glossed over in the post. You would need access to a client app directly to be able to inspect its storage or sniff the traffic yourself to determine the token being used.
Access to an unencrypted client device is usually game over for most apps' data security anyway.
> While I agree that the tokens must be expired on logout
Is there really that much additional security over deleting tokens locally when logging out, but expiring all existing tokens (using a timestamp) on password change?
Blacklisting individual tokens requires storing them in the db and then looking them up each time a user logs in. It seems like given the app already uses TLS, the tiny security gain isn't big enough to justify the performance impact.
I agree although I think about it more in terms of development and maintenance effort.
There's plenty of other relatively computationally and IO intensive activity happening during login so I can't see an extra select having a tangible impact to performance.
The issue isn't tokens getting created on login, it's them getting validated on every request. That's already 40-50ms, even without the db hit each time.
Not that hard. It's pretty easy to social engineer a typical not-HN user to install an arbitrary root cert to the trusted store.
Another commenter mentioned certificate pinning, and it Peach does this, and refuses non-secure API requests, I'd agree it's overblown. It is a vulnerability, yes, but where's the exploit?
An honest query to add on: wouldn't a nonce-style expiration digest be sufficient to prevent this hypothetical reply attack from being effective once the nonce expired?
Wesley, The readability of your blog is rather poor. You might want to change the default width `font-size: 2vw;` to a fixed width (Use rem or em). Current css settings are not user friendly and breaks the browser zoom.
When the author of a website does this, there are a few tricks you can use in modern browsers to help.
In Firefox shift+ctrl+m launches a developer tool that allows you to resize the viewport (for testing responsive designs) without having to resize your browser.
Also available in Firefox (and even nicer) is the Reader View, which works on this blog post. Its icon should be visible on the right hand side of the address bar.
The official Peach app uses SSL and they also do certificate pinning in the requests, that's not a problem. The problem is that Peach's server side authorisation token does not expire when you 'log out' and you can reuse the token.
The issue is mainly got to do with third party apps + this flaw in Peach's API. There is already one[0] which has reversed the Peach API, and the flaw is still present. What happens when another third-party Peach app comes out and does not use SSL, you can still use Peach's API without SSL and it does not default to HTTPS.
This sort of flaw would lead to a similar issue to the Snapsaved leak[1].
Then a major factor in this vulnerability is that the API does not exclusively use TLS to secure all communication. You might want to clarify that in the blog post.
I get that non-expiring tokens are a Bad Idea™, but it's complete bullshit that this is a groundbreaking security flaw. Any service that uses Bearer tokens for request authorization is "vulnerable" under these terms -- regardless of whether or not tokens are invalidated on "logout." What's to say a malicious MITM isn't going to hijack your account while you're still logged in?
Secure infrastructure isn't the one and only solution, but it certainly means that "vulnerabilities" like this are pointless unless your malicious attacker either has the remote server certs or has cracked TLS.
So thoughts on an actual solution? Invalidating tokens means you have to maintain an infinite growing list of invalidated tokens and perform a lookup on every login - somewhat defeating the purpose of 'stateless' tokens like JWTs (ie why not just implement a traditional session store then).
Furthermore, if sniping someone's token like this was doable over MITM, what's to prevent someone from grabbing a live token and then infinitely refreshing it (provided there's a /refresh endpoint).
I'm really wondering if anyone has best practices around this because I have not seen anything.
Good point. I wonder if it is sensible to limit the number of refreshes permitted (by placing a counter in the JWT that gets decreased on every refresh). That way you could have the JWT be valid for, say, 30 minutes, and allow up to seven refreshes; after four hours you would have to re-authenticate.
As for invalidating tokens; if tokens expire after a sensible interval (as they should), than you would only have to maintain a short list of recently issued and invalidated tokens. Older tokens can be removed from that list, because they cannot be used in any case after expiring. You could use a cache with a TTL set to a bit over the configured expiration interval.
The problem is that having a counter doesn't really work, because you can't force the client to take the updated JWT. (And the previous JWT is still valid as it's checked based on signature.)
The way to go is pretty simple - issue a long-term refresh token, and a very short-term JWT to the client (as little as 5 mins or so). The app can then make requests directly to the services, which can independently verify the validity of the JWT.
The services then also check for tokens which have been revoked - using a very fast mechanism, like holding them in-memory or querying a Redis store. The token's JTI only needs to be held in the revocation list for a short period of time - until the JWT expiry time - using a TTL in Redis, or similar.
The app uses the refresh token to get replacement JWTs. It goes with the refresh token directly to the auth service, which can then check whether the user should be able to get new tokens or not.
When you use JWT with the option to refresh the tokens, you usually set an expiry date on the token (if not, there is no point in refreshing at all). So in order to stay authenticated, the client application has to refresh the token a short while before it actually expires and use the new one (which has an updated expiry date) or simply get signed off.
The previous token expires automatically — a well-designed back-end checks against the expiry date and any other claims that should be verified, as well as the signature. So you can force clients to accept the new token with a counter that gets decremented at each refresh until you have to re-authenticate.
There is no need for a separate long-term refresh token.
So the article title could be changed to "Peach API has replay vulnerability"?
I haven't actually tried this yet but can someone confirm the app has pinning? If so, thoughts on how he sniffed the original traffic and ran the replay?
34 comments
[ 0.22 ms ] story [ 75.7 ms ] threadAccess to an unencrypted client device is usually game over for most apps' data security anyway.
[0] https://www.ssllabs.com/ssltest/analyze.html?d=v1.peachapi.c...
(OP: love the graphic design and appropriate color scheme!)
There exists a vulnerability, because the Peach tokens (seemingly) never expire, and thus are vulnerable to replay attacks.
However, because authorization uses TLS, it's very unlikely it will be exploited, because TLS mitigates MITM attacks.
Is there really that much additional security over deleting tokens locally when logging out, but expiring all existing tokens (using a timestamp) on password change?
Blacklisting individual tokens requires storing them in the db and then looking them up each time a user logs in. It seems like given the app already uses TLS, the tiny security gain isn't big enough to justify the performance impact.
There's plenty of other relatively computationally and IO intensive activity happening during login so I can't see an extra select having a tangible impact to performance.
Another commenter mentioned certificate pinning, and it Peach does this, and refuses non-secure API requests, I'd agree it's overblown. It is a vulnerability, yes, but where's the exploit?
An honest query to add on: wouldn't a nonce-style expiration digest be sufficient to prevent this hypothetical reply attack from being effective once the nonce expired?
Thanks.
In Firefox shift+ctrl+m launches a developer tool that allows you to resize the viewport (for testing responsive designs) without having to resize your browser.
Also available in Firefox (and even nicer) is the Reader View, which works on this blog post. Its icon should be visible on the right hand side of the address bar.
The issue is mainly got to do with third party apps + this flaw in Peach's API. There is already one[0] which has reversed the Peach API, and the flaw is still present. What happens when another third-party Peach app comes out and does not use SSL, you can still use Peach's API without SSL and it does not default to HTTPS.
This sort of flaw would lead to a similar issue to the Snapsaved leak[1].
[0] http://techcrunch.com/2016/01/14/peach-gets-an-unofficial-we...
[1] http://techcrunch.com/2014/10/13/snapsaved-takes-responsibil...
Highly annoying!
Secure infrastructure isn't the one and only solution, but it certainly means that "vulnerabilities" like this are pointless unless your malicious attacker either has the remote server certs or has cracked TLS.
Furthermore, if sniping someone's token like this was doable over MITM, what's to prevent someone from grabbing a live token and then infinitely refreshing it (provided there's a /refresh endpoint).
I'm really wondering if anyone has best practices around this because I have not seen anything.
As for invalidating tokens; if tokens expire after a sensible interval (as they should), than you would only have to maintain a short list of recently issued and invalidated tokens. Older tokens can be removed from that list, because they cannot be used in any case after expiring. You could use a cache with a TTL set to a bit over the configured expiration interval.
The way to go is pretty simple - issue a long-term refresh token, and a very short-term JWT to the client (as little as 5 mins or so). The app can then make requests directly to the services, which can independently verify the validity of the JWT.
The services then also check for tokens which have been revoked - using a very fast mechanism, like holding them in-memory or querying a Redis store. The token's JTI only needs to be held in the revocation list for a short period of time - until the JWT expiry time - using a TTL in Redis, or similar.
The app uses the refresh token to get replacement JWTs. It goes with the refresh token directly to the auth service, which can then check whether the user should be able to get new tokens or not.
The previous token expires automatically — a well-designed back-end checks against the expiry date and any other claims that should be verified, as well as the signature. So you can force clients to accept the new token with a counter that gets decremented at each refresh until you have to re-authenticate.
There is no need for a separate long-term refresh token.
I haven't actually tried this yet but can someone confirm the app has pinning? If so, thoughts on how he sniffed the original traffic and ran the replay?
[0] https://github.com/nabla-c0d3/ssl-kill-switch2 [1] http://mitmproxy.org/