Hi, after some profiling (thanks to Garvin for the hint about xdebug), I found that using a blowfish encryption coded in php was taking about 70-80% of the execution time every time we encrypt or decrypt. And since we have the security feature of adding the current time to username and password cookie (which makes a stolen cookie useless after LoginCookieValidity seconds), we encrypt and decrypt on each click!
Thanks to Michal for the suggestion of using mcrypt. It's now used instead of blowfish.php (if available), producing dramatic speed improvements.
I will add in the doc a strong suggestion to use this library.
Meanwhile, please test :)
Marc
Hi Marc!
About the LoginCookieValidity - a question: Since I don'T use cookie auth, is it possible for users to set LoginCookieValidity off (say to 0) and then the en/decoding of the cookie is not always performed?
If that's not yet the case, I'd suggest to do so, because I suppose some users may want to use cookies, don't have mcrypt but wouldn't need the CookieValidity Setting - so for them, the cookie shouldn't be en/decoded everytime.
Regards, Garvin.
(P.S., Marc: Your mail about the session stuff needs some more thinking from me, but I didn't ignore it :-)
Garvin Hicking a écrit:
Hi Marc!
About the LoginCookieValidity - a question: Since I don'T use cookie auth, is it possible for users to set LoginCookieValidity off (say to 0) and then the en/decoding of the cookie is not always performed?
Hi Garvin, this would mean that a stolen cookie can be used to authenticate.
Marc
If that's not yet the case, I'd suggest to do so, because I suppose some users may want to use cookies, don't have mcrypt but wouldn't need the CookieValidity Setting - so for them, the cookie shouldn't be en/decoded everytime.
Regards, Garvin.
(P.S., Marc: Your mail about the session stuff needs some more thinking from me, but I didn't ignore it :-)
P.S. No problem...
Hi Marc!
Hi Garvin, this would mean that a stolen cookie can be used to authenticate.
Well, but let's say PMA is used on a host which is restricted via IP protection, or an internal server, where you suppose no cookies can/will be stolen - the only way for users without mcrypt would be to not use cookies; instead I would think it would be better to offer them to turn of validity checking in that case.
But then again, I'm not much into all that Cookie-Stealing-Security issues. :)
Regards, Garvin.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi there,
Marc Delisle wrote:
Garvin Hicking a écrit:
About the LoginCookieValidity - a question: Since I don'T use cookie auth, is it possible for users to set LoginCookieValidity off (say to 0) and then the en/decoding of the cookie is not always performed?
Hi Garvin, this would mean that a stolen cookie can be used to authenticate.
First of all, storing the cookie savely is the client's task. If by "stolen cookie" you are talking about someone sniffing my traffic and extracting the encrypted password: Well that's what SSL is made for. On top of that: On login, the user has to send his password unencrypted through the wire: If I wanted to hack someone, I'd grab the password there instead of "steal" the cookie.
We cannot always save the world. The encryption feature is a nice possibility to make PMA a bit more secure for users of Microsoft's Internet Exploiter, but if it slows down PMA that much, we should give the users the ability to switch it off.
Alternatively, we could maybe implement an auth plugin that uses sessions and deprecate the cookie plugin step by step.
Regards,
AMT
Alexander M. Turek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi there,
Marc Delisle wrote:
Garvin Hicking a écrit:
About the LoginCookieValidity - a question: Since I don'T use cookie auth, is it possible for users to set LoginCookieValidity off (say to 0) and then the en/decoding of the cookie is not always performed?
Hi Garvin, this would mean that a stolen cookie can be used to authenticate.
First of all, storing the cookie savely is the client's task. If by "stolen cookie" you are talking about someone sniffing my traffic and extracting the encrypted password: Well that's what SSL is made for. On top of that: On login, the user has to send his password unencrypted through the wire: If I wanted to hack someone, I'd grab the password there instead of "steal" the cookie.
Hi Alexander, no, I am talking about XSS techniques which can be used to get cookies. Obviously we are improving phpMyAdmin against those, but PMASA-2004-3 shows that there probably remains some parts of phpMyAdmin not immune to XSS.
We cannot always save the world. The encryption feature is a nice possibility to make PMA a bit more secure for users of Microsoft's Internet Exploiter, but if it slows down PMA that much, we should give the users the ability to switch it off.
With the new mcrypt module, the slowdown problem is AFAIK solved. I would prefer suggesting users (sysadmins) to implement this extension on their servers if it's not already done, than lowering the security of encrypted cookies.
Alternatively, we could maybe implement an auth plugin that uses sessions and deprecate the cookie plugin step by step. >
Yes we have been talking about this for some time. But remains the point of stealing session data, see for example: http://www.webkreator.com/php/configuration/php-session-security.html
So I would prefer to encrypt username and password stored in the session. Or at least inform users if we can detect that the way session data is stored is too much open to intrusion.
Marc
Regards,
AMT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBpL2z8c/ssWf/SMcRAmWPAJ0bmrrUqFnoB/VevSYUquulPpx2UACfYHR2 4YZNVSDA9Wkcaiv5j/ZWKlM= =DeAf -----END PGP SIGNATURE-----
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-
Alexander M. Turek -
Garvin Hicking -
Marc Delisle