Earlier quoted context omitted.
Fantastic. Is this the defacto tool? Can this be done without a tool?
On windows? Try fiddler: http://www.telerik.com/fiddler
Fiddler works on all platforms. It is my proxy cap tool of choice.
Peach App Token Reuse Flaw
21–30 of 35 posts
Re: Peach App Token Reuse Flaw
#22What tool does one use to inspect requests?
Burp is great too: https://portswigger.net/burp/
Re: Peach App Token Reuse Flaw
#23So 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?
Re: Peach App Token Reuse Flaw
#24While 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'…
> 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 eno…
[deleted]
Re: Peach App Token Reuse Flaw
#25So 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…
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.
Re: Peach App Token Reuse Flaw
#26Wesley, 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. Thanks.
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.
Re: Peach App Token Reuse Flaw
#27Am I misunderstanding something, or wouldn't this just be solved if they simply used SSL for all communications?
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 a…
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.
Re: Peach App Token Reuse Flaw
#28While 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'…
> 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 eno…
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.
Re: Peach App Token Reuse Flaw
#29So 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…
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 m…
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.
Re: Peach App Token Reuse Flaw
#30Earlier quoted context omitted.
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 m…
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 v…
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.