24 Nov
2004
24 Nov
'04
2:39 a.m.
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
24 Nov
24 Nov
3:48 a.m.
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 | Web-Entwickler [PHP] | www.supergarv.de | ICQ 21392242
++ Developer of | www.phpMyAdmin.net | www.s9y.org
++ Make me happy | http://wishes.garv.info
4:07 a.m.
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...
4:31 a.m.
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.
--
Garvin Hicking | Web-Entwickler | Make me happy:
www.supergarv.de | #ICQ 21392242 | http://wishes.garv.info/
6:04 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
Marc Delisle wrote:
Garvin Hicking a écrit:
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
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. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBpL2z8c/ssWf/SMcRAmWPAJ0bmrrUqFnoB/VevSYUquulPpx2UACfYHR2
4YZNVSDA9Wkcaiv5j/ZWKlM=
=DeAf
-----END PGP SIGNATURE-----
7:28 a.m.
Alexander M. Turek wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
Marc Delisle wrote:
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.
Garvin Hicking a écrit:
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. 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.
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
7227
days inactive
7227
days old
5 comments
3 participants
participants (3)
-
Alexander M. Turek -
Garvin Hicking -
Marc Delisle