[GitHub] [couchdb] tabeth edited a comment on issue #844: Add new explicit authentication-tokens that can be revoked

[GitBox <gi...@apache.org>]

tabeth edited a comment on issue #844: Add new explicit authentication-tokens that can be revoked
URL: https://github.com/apache/couchdb/issues/844#issuecomment-478559826
 
 
   @rnewson 
   
   I will. I'll also try to summarize briefly our findings here when I start that thread. 
   
   
   @realulim 
   >The exploit is that a stateless token, once stolen, can be used indefinitely by the attacker.
   
   I don't disagree, but it's worth elaborating here. Assuming tokens are not set to be `persistent` (in which case doing what I described above is the only option anyway), there are effectively three paths: 
   
   ## Path 1
   Imagine a user's usage history looks something like this:
   - `GET _session` -> Cookie1 (Expiry at +10 minutes)
   - `GET _db` (Cookie1) -> Cookie2 (Expiry at +11 minutes)
   - `GET _db/1` (Cookie 1) -> Cookie3 (Expiry at +12 minutes)
   - `GET _db/2` (Cookie 1) -> Cooke4 (Expiry at +13 minutes)
   
   As you can see, using our original cookie, `Cookie1`, through completely normal usage we've incidentally created 3 other cookies, `Cookie2`, `Cookie3`, and `Cookie4`. In a normal application, despite the generation of the new cookies, `Cookie1` would be the one used until near expiration, in which case a new cookie would be generated. A "soft" logout, that only invalidates a specific cookie would just be to blacklist Cookie1 until expiry. 
   
   ## Path 2
   Using the same usage history as above, you could imagine that a malicious hacker somehow gets access to `Cookie2`, `Cookie3`, or `Cookie4` and uses that to generate new cookies indefinitely (perhaps by just requesting access to `_db` in this case. 
   
   Assuming the hacker did this without a trace (meaning we don't know how they got the cookies), their behavior would be indistinguishable from our user's. If all we had was a hunch all we could do is just invalidate all of the sessions for the user. After this we'd have to send them a temporary password to use to access their account. 
   
   ## Path 3
   This would be the exact scenario as Path 2, however instead of invalidating all of the sessions for the user, we would just ask them to "login", and on the client side we would actually log them out and immediately log them in, locking out the hacker and giving them access again. The main reason to do this is so we don't have to send them a new password.
   
   In other words, if we suspect Path 2 is occurring, we set a flag and the next time they log in, on the client side we implement it as a "log out" followed immediately by "log in". 
   
   
   ---
   
   In my opinion the security concern can already be addressed. The goal, however would be to implement a "soft logout" via a blacklist, so that when users logout their tokens are explicitly logged out. This, combined with a sufficiently short expiry time, e.g. 10 minutes, would address 99.9% of the security concerns. 
   
   If you consider the situation proposed in Path 1, if there was a blacklist, and a user "logged out" after the last item in their history, a user would only have a 4 minute window to grab either `Cookie2`, `Cookie3`, or `Cookie4`, the only 4 cookies that haven't explicitly been blacklisted. After this window, `Cookie1` would not work due to the blacklist and due to expiring, and the rest of them would have expired. A hacker would have no cookie to used and all is well.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services