Menu
▾
▴
phpwiki-talk
|
From: Reini U. <ru...@x-...> - 2003-12-03 16:32:07
|
Carsten Klapp schrieb: > Update of /cvsroot/phpwiki/phpwiki/lib > In directory sc8-pr-cvs1:/tmp/cvs-serv19754 > > Added Files: > WikiUserNew.php > Log Message: > Complete rewrite of WikiUser.php. > > This should make it easier to hook in user permission groups etc. some > time in the future. Most importantly, to finally get UserPreferences > fully working properly for all classes of users: AnonUser, BogoUser, > AdminUser; whether they have a NamesakePage (PersonalHomePage) or not, > want a cookie or not, and to bring back optional AutoLogin with the > UserName stored in a cookie--something that was lost after PhpWiki had > dropped the default http auth login method. aah, good. thats what jeff wanted from me. thanks -- Reini Urban |
|
From: Reini U. <ru...@x-...> - 2003-12-13 01:00:17
|
Joby Walker schrieb: > This looks good, but as I read this you are storing the > username&password (in human readable form) in the contents of a cookie > on the end-user's machine. This seems quite bad to me. SOP, for web > sites is to store a cookie with a unique id (UID). The cookie id plus > some unique features of the client (IP, browser, time, etc) are then > checked by the server against it's session database and if verified the > user is logged in (very similar to Kerberos). But by storing the > username & password in the cookie, it someone reads the cookie they will > have complete access to that account. > > A quick review of the cookies currently in my broswer shows: > > 1) UID's are primarily used -- especially with commercial sites. > 2) Passwords are not stored in cookies. > 3) Userid's, if used instead of a UID, are encrypted. > 4) Very little data is in human readable form -- and none of it is > critical info. > > If I am mistaken about what you are storing in the cookie ... then > ignore. But I am quite worried about this development. Well, I'm not so concerned about security with this password issue, since it's only a wiki. nothing serious. If I store sensitive data in cookies I do a symeteric encryption with a secret key at the host, generated at install time. but it's true that certain pref data shouldn't be stored in cookies: passwd (for security), email (. just the basic prefs for username and layout. otherwise the user has to create a homepage. okay? but then we'll have to fix the login procedure also. > On a better note the classes look good. Having different classes with > common methods will be very helpful for the future of phpwiki. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Bishop <bi...@pl...> - 2003-12-13 21:14:19
|
> Joby Walker schrieb: >> If I am mistaken about what you are storing in the cookie ... then >> ignore. But I am quite worried about this development. > > Well, I'm not so concerned about security with this password issue, > since it's only a wiki. nothing serious. I've just read the section of code allowing me to use the imap authentication feature, which means my wiki passwords will be the same as my users' imap passwords - therefore the same as their account passwordson my mail server. The risk of having those passwords stored remotely or passed over an insecure connection is a bit of a concern. PHPWiki runs well over an SSL connection, right? > If I store sensitive data in cookies I do a symeteric encryption with a > secret key at the host, generated at install time. Where's that part of the code? I want to make sure it's being run like it should on %post in the RPM as well. > but it's true that certain pref data shouldn't be stored in cookies: > passwd (for security), email (. just the basic prefs for username and > layout. > otherwise the user has to create a homepage. > okay? Okay. Phew. Thanks. |
|
From: Joby W. <joby@u.washington.edu> - 2003-12-15 20:03:33
|
Reini Urban wrote: > Joby Walker schrieb: > > Well, I'm not so concerned about security with this password issue, > since it's only a wiki. nothing serious. The wiki that I manage is quite critical and contains a lot of data we don't want to fall into hostile hands... > If I store sensitive data in cookies I do a symeteric encryption with a > secret key at the host, generated at install time. > but it's true that certain pref data shouldn't be stored in cookies: > passwd (for security), email (. just the basic prefs for username and > layout. > otherwise the user has to create a homepage. > okay? I still wouldn't do it this way. I would: Cookie: Contents = a 64 character hex number [md5(random data1) . md5(random data2)] SSL = configurable yes/no Expire = configurable Server Session Validation: Cookie Content ID Browser Used IP# Expiration Time If the cookie points to a valid session then the user is logged into as the saved (as a part of the session) username and given the associated saved preferences. This will allow for a more secure "auto-login" process -- if a cookie is compromised then it will contain no hard data (encrypted or not) with a fairly limited vulnerability window. And once the session attached to that cookie contents has expired -- the data is completely useless. And allows admins to dynamically set the expiration time of sessions (from never to very short times) even after the cookie has been set on the user's computer. > > but then we'll have to fix the login procedure also. > >> On a better note the classes look good. Having different classes with >> common methods will be very helpful for the future of phpwiki. I absolutely agree. My quibble is with an implimentation detail not the general architecture. These classes will make things MUCH easier. jbw |
|
From: Carsten K. <car...@us...> - 2003-12-13 07:13:56
|
On Friday, December 12, 2003, at 10:52 am, Joby Walker wrote: > Carsten, > > This looks good, but as I read this you are storing the > username&password (in human readable form) in the contents of a cookie > on the end-user's machine. This seems quite bad to me. SOP, for web > sites is to store a cookie with a unique id (UID). The cookie id plus > some unique features of the client (IP, browser, time, etc) are then > checked by the server against it's session database and if verified > the user is logged in (very similar to Kerberos). But by storing the > username & password in the cookie, it someone reads the cookie they > will have complete access to that account. > > A quick review of the cookies currently in my broswer shows: > > 1) UID's are primarily used -- especially with commercial sites. > 2) Passwords are not stored in cookies. > 3) Userid's, if used instead of a UID, are encrypted. > 4) Very little data is in human readable form -- and none of it is > critical info. > > If I am mistaken about what you are storing in the cookie ... then > ignore. But I am quite worried about this development. > > On a better note the classes look good. Having different classes with > common methods will be very helpful for the future of phpwiki. > > jbw > > Carsten Klapp wrote: > >> Update of /cvsroot/phpwiki/phpwiki/lib >> In directory sc8-pr-cvs1:/tmp/cvs-serv19754 >> Added Files: >> WikiUserNew.php Log Message: >> Complete rewrite of WikiUser.php. Hi Joby, Thank you for the feedback, I always appreciate it! I finally got my own wiki up and running again (see http://phpwiki.sourceforge.net/phpwiki/KnownBugs, search for OldTextFormattingRules) so the good news is I'll be able to do extensive testing on the WikiUserNew stuff before deploying it into PhpWiki CVS. Rest assured, it's always been my intention to make sure the password will be stored encrypted, whether in a cookie or within the homepage, so long as the PHP module is compiled to allow the function crypt(). I'm sure the WikiUserNew.php doesn't completely reflect all this yet in its current state, but I'll make sure it does in upcoming versions. :) As far as storing the password itself (encrypted or not) within a cookie for auto-login, I'm not too concerned at the moment, especially about encrypting WikiUserIds. As Reini said, "it's only a wiki." It's pretty commonly known that UserIds on a wiki are just the UserName. But if a user were to enable (the upcoming feature) "auto-login", I believe for now it should be sufficient enough upon enabling AutoLogin to just give the user a quick reminder message that, "anyone could potentially log in from that machine when auto-login is enabled" or something similar. (Joby, please do remind me later if I somehow forget to do this(:). Once banks or other financial institutions decide to start using PhpWiki ;) there's no reason why we can't (hopefully, be paid to) revisit the code. In that case those sites would definitely be using TSL/SSL too; not that it would *completely* alleviate the need for internally encrypted passwords but it makes coding some other things a little easier. So rereading your message, I think it would indeed be best to continue to use the PHPSESSION cookie stuff wherever possible as you suggest, like PhpWiki 1.3.6/7pre currently does, to keep the cookie-passing to a minimum until such time as a user actually changes and saves his/her UserPreferences. Where the prefs & passwd are stored of course will depend on the type of user (AnonUser, BogoUser, PassUser, AdminUser, etc.) A little more work to the new code will be needed for all that but I think that's the way I'm going to go. And as the NewWikiUser code evolves too please continue to let me know if there's anything that might need changing or more thought. Since we're talking about security here, naturally any follow-ups or concerns are welcome from anyone: I don't mean to imply IKnowEverything/ISeeAll here... Cheers, Carsten |
|
From: Reini U. <ru...@x-...> - 2003-12-14 14:50:13
|
Bishop schrieb: >>Joby Walker schrieb: >>>If I am mistaken about what you are storing in the cookie ... then >>>ignore. But I am quite worried about this development. >> >>Well, I'm not so concerned about security with this password issue, >>since it's only a wiki. nothing serious. > > I've just read the section of code allowing me to use the imap > authentication feature, which means my wiki passwords will be the same as > my users' imap passwords - therefore the same as their account passwordson > my mail server. The risk of having those passwords stored remotely or > passed over an insecure connection is a bit of a concern. in case of external auth no passwords are stored anywhere. it just checks for the correctness of the given username/password. in case of external prefs (customizable with external auth also), also the other prefs are not stored in any page or cookie. in case of loose PagePermissions and homepage stored prefs one could look at prefs of other users, with the metadata viewer plugin. > PHPWiki runs well over an SSL connection, right? PHPWiki runs well over an HTTPS connection, if the images are also on HTTPS (no external img src). otherwise you get lot of warnings. I never did an IMAP connection over a secured connection (SSL, TLS, ...) yet. imap_open does support TLS/SSL if compiled against OpenSSL. stunnel is the other possibility: see http://security.fi.infn.it/tools/stunnel/index-en.html If this is not possible or the imap server does not support TLS/SSL, the given password is passed cleartext to the IMAP server (AUTH=PLAIN), same as with every unsecured mail client connection. >>If I store sensitive data in cookies I do a symeteric encryption with a >>secret key at the host, generated at install time. > > Where's that part of the code? I want to make sure it's being run like it > should on %post in the RPM as well. in other projects of mine. in my tep addons (oscommerce.org) for example. not in phpwiki yet. >>but it's true that certain pref data shouldn't be stored in cookies: >>passwd (for security), email (. just the basic prefs for username and >>layout. >>otherwise the user has to create a homepage. >>okay? > Okay. Phew. Thanks. nada. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Bishop <bi...@pl...> - 2003-12-15 06:28:35
|
> Bishop schrieb: >>>Joby Walker schrieb: >>>>If I am mistaken about what you are storing in the cookie ... then >>>>ignore. But I am quite worried about this development. >>> >>>Well, I'm not so concerned about security with this password issue, >>>since it's only a wiki. nothing serious. >> >> I've just read the section of code allowing me to use the imap >> authentication feature, which means my wiki passwords will be the same >> as >> my users' imap passwords - therefore the same as their account >> passwordson >> my mail server. The risk of having those passwords stored remotely or >> passed over an insecure connection is a bit of a concern. > > in case of external auth no passwords are stored anywhere. > it just checks for the correctness of the given username/password. > > in case of external prefs (customizable with external auth also), also > the other prefs are not stored in any page or cookie. Okay. as long as the cookie (can be set so that it) doesn't contain any auth info that can be grabbed from a sniffed HTTP:80 connection, that's fine. > in case of loose PagePermissions and homepage stored prefs one could > look at prefs of other users, with the metadata viewer plugin. So we know we shouldn't do that. >> PHPWiki runs well over an SSL connection, right? > > PHPWiki runs well over an HTTPS connection, if the images are also on > HTTPS (no external img src). otherwise you get lot of warnings. Excellent. An admin who wants to secure the wiki from shenanigans, then, should - run ssl - use imapssl for auth (with that path o' mine) - not set loose pagePermissions > I never did an IMAP connection over a secured connection (SSL, TLS, ...) That works. I'm auth'ing to my demo server with usernames/passwords on a remote imaps server (and tethereal shows it's only accessing port 993; not 143). The patch is tiny, and I'm glad phpwiki uses the standard imap_open stuff like it should - passing in 993/imaps/noverify or whatnot (see the patch) works like a dream. > yet. imap_open does support TLS/SSL if compiled against OpenSSL. > stunnel is the other possibility: > see http://security.fi.infn.it/tools/stunnel/index-en.html > If this is not possible or the imap server does not support TLS/SSL, the > given password is passed cleartext to the IMAP server (AUTH=PLAIN), same > as with every unsecured mail client connection. Yeah, that's to be expected. I'm also thankful that the UW people made an IMAP daemon that the RH people could package into something I can secure easily, and I'm am doing my part to campaign for only imapS (and pop3S) among the users on the mail server I use. 8-) >>>If I store sensitive data in cookies I do a symeteric encryption with a >>>secret key at the host, generated at install time. >> >> Where's that part of the code? I want to make sure it's being run like >> it >> should on %post in the RPM as well. > > in other projects of mine. in my tep addons (oscommerce.org) for > example. not in phpwiki yet. Okay. I'll check back if I hear of anything generated at install time, so that it's generated on installation of the package instead of make-install portion of the package-building bit, so the keys are all randomly different. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X