> AFAIK, there's no *simple* mean to solve what you called an issue. Indeed, but it does not make it a non-issue ;-)
> I don't want to describe all the gory details here (you may see > [1],[2] and the PHP documentation for references), but basically > PmWiki uses the session data as a backup of what the user typed in the > password field, which then could be re-used as is by all the auth > chain each time a new wiki page is requested (submitted with or > whithout preliminary encryption to the configured auth scheme as > required). Ideally this design should be adapted, but it is probably not realistic to expect such a change now. Maybe for a future major version ? > So, encrypting the session data would require to use a two-way > encryption cypher and a dedicated password in order to be able to > retrieve the original data. Then, where would you store this password? There is indeed little choice: in one of the configuration files. > Corollary question: If someone is able to look at your session datas, > how could you prevent him to have also a look at your config.php? You can't. But it would require some more effort (you have to know about it, then you have to know where to look for the password, then you have to be willing and able to program an adequate decryption function). Far from perfection, but much better than just having to open the session files to read the users (LDAP) passwords in clear. > Finally, did you know that the password you entered in the auth field > was sent without any encryption from your browser to the server > hosting your wiki? Yes, but therefore you need to "snif" the network, which is not available to everyone. And it can be avoided by using SSL (even with a self-signed certificate). I would advocate for a reasonable extra effort to at least not *STORE* the passwords in clear in PHP session files, even if the "solution" is not totally secure. This would be much better than having nothing because we cannot have everything. As the password would be stored in a configuration file, there is no need to use strong encryption. Basically, XORing the password and name the session variable something that does not suggest it contains a password would probably be a reasonable step forward. Christophe ---- _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
