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.
FS#2536 admin password stored with weak encryption method
Just after installation of Dokuwiki, in admin / Configuration Settings / Authentication Settings / Password encryption method, the default value is md5
md5 is a very weak encryption method (see rainbow table on wikipedia), so any responsible admin change immediately this value to something more secure, let us say SSHA
Therefore, all users accounts are created with a SSHA (salted SHA) password encoding, and that is safe.
The problem is that during install, the admin password has been encrypted with md5 (default password encryption method), and stored as such on disk. Therefore, the admin password remains the only one with a very weak encryption. This is a security problem.
Prefered solution : define SSHA (or another secure password encoding) as the default encoding method.
Other solution : if the "Password encryption method" is modified, logout everybody from the wiki, forcing people to login again. On login, check the password with the password encoded as stored, and if the password is ok, behave as if the user has just modified his password by a new one (the same one) and store the "new" password with the new Password encryption method. This way, if the admin modify the Password encryption method, he/she is logged out, login again, and during the login process, his stored password is updated with the new Password encryption method.
The default password encryption method is salted md5, and rainbow tables don't work for salted hashes. Rainbow tables work both for sha1 and md5, there is no difference here, just that rainbow tables for md5 are more widespread.
As far as I'm aware there is no danger for (salted) passwords hashed with md5 as - as far as I'm aware - there is no known attack of practical relevance against md5 which allows you to compute a string which results in a given hash (the existing attacks make it only possible to get two inputs with the same hash by modifying a certain block of data in both inputs). Therefore I don't see why - taking the currently known attacks and available computing power into account - ssha should be more secure than the default smd5. Maybe it would make sense to check the availability of bcrypt at install time and chose bcrypt as default if that's the case? Once we require PHP 5.3 I think it would make sense to switch to bcrypt as default as hash functions which need more time to be evaluated are the only protection against dictionary-based attacks. Until then maybe one of the chained md5 methods could make sense in order to increase the time required for dictionary attacks, however I'm not sure how much that really helps. I think the point is that we are still rather far away from attacks which break md5 in a way that is dangerous for password hashes and the real problem with password hashes are dictionary-based attacks against weak passwords that are executed on highly parallel hardware and distributed around the world.
Btw. DokuWiki can know the password of the user in each request as it is encrypted in the login cookie so there is no need for logout/login, the stored hash could be updated in every request where the user is logged in.
Michi, the problem this report addresses is the password generated in the installer. installer.php does not use the PassHash class currently but stores a simple MD5 crypted password with no salt. As this password is unlikely to be changed by the admin, I agree that this is a bad situation.
Our intitial approach to install.php was to make it as indepent as possible from the rest of the code, because all the initializations can not be run before the config has been set. However, the PassHash class has no dependencies it self, so it should be possible to use it in the installer and use a more secure method, eg. SMD5.
Oh, okay, I wasn't aware of this problem and can't really derive this from the bug report. I think using PassHash in the installer sounds like a good solution. I think it might also be a good idea to update the password hash during password verification in the plain auth backend when the current encryption method is not the one that is used for the stored password in order to fix this in existing installations (of course only when the users file is writable).
fixed in 3791b589 If you want password rehashing for existing users, please open another feature request.