5 ms·
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]! Thi
by narsil 11y ago
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.
[0] https://www.ssllabs.com/ssltest/analyze.html?d=v1.peachapi.com&hideResults=on https://www.ssllabs.com/ssltest/analyze.html?d=v1.peachapi.c...
(OP: love the graphic design and appropriate color scheme!)
- Gigablah 11y agoYeah, that's important missing info. I was initially dumbfounded at the apparent lack of HTTPS.
- dthakur 11y agoSounds like a storm in a teacup if indeed the endpoint is served over TLS.
- balls187 11y agoWell, no. Rather it's a threat vs vulnerability case. 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.
- Alex3917 11y ago> 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.
- deleted 11y ago[deleted]
- dwightgunning 11y agoI 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.
- Alex3917 11y agoThe 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.
- spdustin 11y agoNot 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?