This is a static dump of issues in the old "Flyspray" bugtracker for DokuWiki. Bugs and feature requests
are now tracked at the issue tracker at Github.
Open
This task was never closed in our old bug tracker.
Feel free to open a new task at Github if you feel this is still relevant.
FS#2796 Make sticky login cookies (automatically) expirable
Security
2013-06-03Michitux
Currently whoever gets access to a sticky login cookie will be able to use the DokuWiki account of the owner of the cookie as he long as he doesn't change the password. This could for example happen if you forgot to logout on a public/shared computer and enabled sticky logins by accident. There is also no way to let sticky login cookies expire after a certain period of time.
I therefore suggest to implement a new mechanism for sticky login cookies that's still rather simple but allows to expire sticky login cookies and optionally also supports more than one sticky login cookie per user.
The basic problem is that DokuWiki needs to have the actual plaintext password available in every request as external authentication backends might need it.
The idea is to split the cookie value into two parts using XOR: After encrypting the username and password generate a random value of the same length. Store this random value on the server. Send the XOR of the random value and the encrypted password to the client as cookie. Then the XOR of the cookie and the random value on the server is again the original encrypted password. The server storage can be the session for non-sticky login cookies but for sticky login cookies we would need a new mechanism. I suggest to use one file per user which might even be part of a more general user settings storage. In this file either a single random value could be stored (then the XOR value for the cookie would be calculated again when the user logs in a second time and the token could be deleted on a logout) or several values could be stored so the user could have several different sticky login cookies. In order to identify the user of a certain login cookie we most probably need to store the login name in the cookie, too, or store a file named after a (strong) hash of the login cookie with the username as content but as this creates an additional attack vector for the data on the server I would prefer the first option.
Some rationale behind these ideas: The random value might not be random enough (http://phpsecurity.readthedocs.org/en/latest/Insufficient-Entropy-For-Random-Values.html) and we definitely don't want the encrypted password to be stored on the server as the key is also on the server. That's why I suggest to store the random value on the server and not the result of the XOR. Furthermore if we sent the random value to the client attackers might be able to guess the next login cookies by looking at their own login cookies as the consecutive random values for consecutive login cookies might be based on the same seed. By sending the encrypted password the security will still be at least as good as it is currently but in addition if an attacker gets a login cookie it can be invalidated and in order to derive a new login cookie he would need to guess two random values that are most probably based on different seeds and where he cannot know if he has correctly guess one of the two random values which should provide adequate security even with weak random values.
2013-07-09Michitux
A very simple idea for making the sticky login cookie expirable after a certain time is to include the current timestamp in the string that is encrypted. That way after decrypting the string we could check if the cookie is still valid. The sticky login cookie could then also be refreshed whenever the user accesses the site. This could be combined with the suggestions above.
2013-08-01ChrisS
Per discussions at Hackfest 2013.
The way to invalidate login cookies (both stick & non-sticky) is to change your password.
Sticky login cookies are a convenience where the implied security comes from the physical security of the client. Its the user's responsibility to choose to use a sticky when they are confident in their client security.
There is an issue with non-sticky login cookies, which don't put the same implied security requirements on the user, but when combined with the session cookie provide a transferrable, non-expirable (stealable) login mechanism. The convenience of not being logged out of the wiki while your browser remains open - even if PHP garbage collects the session - is a feature we don't want to lose.
It maybe feasible to introduce:
- a config option to disable non-sticky login cookies
- a plugin which maintains lists of valid login cookies which could prevent invalid login cookies (where the original user of the cookie has explicitly logged out) being used to access the wiki.