phpwiki-talk

[Phpwiki-talk] WikiUser.php REQUIRE_EMAIL_VERIFICATION and User classes

[Reini U. <ru...@x-...>]

Carsten Klapp schrieb:
> Modified Files:
> 	WikiUser.php 
> Log Message:
> Security bugfix (minor): Prevent BogoUser~s from saving extraneous
> _pref object meta-data within locked pages.
> 
> Previously, BogoUser~s who signed in with a (valid) WikiWord such as
> "HomePage" could actually save preferences into that page, even though
> it was already locked by the administrator. Thus, any subsequent
> WikiLink~s to that page would become prefixed with "that nice little"
> UserIcon, as if that page represented a valid user.
> 
> Note that the admin can lock (even) non-existant pages as desired or
> necessary (i.e. any DB page whose revision==0), to prevent the
> arbitrary BogoUser from saving preference metadata into such a page;
> for example, the silly WikiName "@qmgi`Vcft_x|" (that is the
> \$examplechars presented in login.tmpl, in case it is not visible here
> in the CVS comments).
> 
> http://phpwiki.sourceforge.net/phpwiki/
> %C0%F1%ED%E7%E9%E0%D6%E3%E6%F4%DF%F8%FC?action=lock
> 
> To remove the prefs metadata from a page, the admin can use the
> EditMetaData plugin, enter pref as the key, leave the value box empty
> and then submit the change. For example:
> 
> http://phpwiki.sourceforge.net/phpwiki/
> _EditMetaData?page=%C0%F1%ED%E7%E9%E0%D6%E3%E6%F4%DF%F8%FC
> 
> (It seems a rethinking of WikiUserNew.php with its WikiUser and
> UserPreferences classes is in order. Ideally the WikiDB would
> transparently handle such a situation, perhaps BogoUser~s should
> simply be restricted to saving preferences into a cookie until his/her
> e-mail address has been verified.)

I think this should be another index.php option.

if (!defined('REQUIRE_EMAIL_VERIFICATION')) 
define('REQUIRE_EMAIL_VERIFICATION',false);

This would go for storing users in the External DB (if allowed),
for the EmailNotification on page changes feature and saving prefs in 
the homepage.

One might need to allow this without EMAIL_VERIFICATION.

Regarding EMAIL_VERIFICATION:
   we need another url action with the sent id as get parameter
(e.g.: phpwiki.sf.net/demo/UserName?verify=48731984718937489312749812)
   and we might need a table to store this pending request id.
   or would it be enough to store the verification id in the userpage 
metadata for this short time.?
   as long as the verify metadata in the users homepage is present, the 
preferences are restricted to cookies.

So will need those new userpref classes:
   CookieUserPref, HomepageUserPref, ExternalFileUserPref and 
ExternalDbUserPref; dependent on where to read/write preferences.

But on the contrary different classes where to read/write authinfo:
   AnonUserAuth, BogoUserAuth, AdminUserAuth (questionable), 
CookieUserAuth, HomepageUserAuth, ExternalImapUserAuth, 
ExternalLdapUserAuth, ExternalFileUserAuth, ExternalDbUserPref.

One could throw away AdminUserAuth because the Anon- and BogoUserAuth 
class methods should check if the given username is the ADMIN_USER and 
force a password on this attempted login. All other classes require a 
password.

Maybe we should provide a ALLOW_EMPTY_PASSWORD config option also, maybe 
also some kind of password strength restriction policy (min 6 chars, ...)

Ok?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] WikiUser.php REQUIRE_EMAIL_VERIFICATION and User classes

[Carsten K. <car...@us...>]

On Saturday, December 6, 2003, at 07:52  am, Reini Urban wrote:

> Carsten Klapp schrieb:
>> Modified Files:
>> 	WikiUser.php Log Message:
>> Security bugfix (minor): Prevent BogoUser~s from saving extraneous
>> _pref object meta-data within locked pages.
>> Previously, BogoUser~s who signed in with a (valid) WikiWord such as
>> "HomePage" could actually save preferences into that page, even though
>> it was already locked by the administrator. Thus, any subsequent
>> WikiLink~s to that page would become prefixed with "that nice little"
>> UserIcon, as if that page represented a valid user.
>> Note that the admin can lock (even) non-existant pages as desired or
>> necessary (i.e. any DB page whose revision==0), to prevent the
>> arbitrary BogoUser from saving preference metadata into such a page;
>> for example, the silly WikiName "@qmgi`Vcft_x|" (that is the
>> \$examplechars presented in login.tmpl, in case it is not visible here
>> in the CVS comments).
>> http://phpwiki.sourceforge.net/phpwiki/
>> %C0%F1%ED%E7%E9%E0%D6%E3%E6%F4%DF%F8%FC?action=lock
>> To remove the prefs metadata from a page, the admin can use the
>> EditMetaData plugin, enter pref as the key, leave the value box empty
>> and then submit the change. For example:
>> http://phpwiki.sourceforge.net/phpwiki/
>> _EditMetaData?page=%C0%F1%ED%E7%E9%E0%D6%E3%E6%F4%DF%F8%FC
>> (It seems a rethinking of WikiUserNew.php with its WikiUser and
>> UserPreferences classes is in order. Ideally the WikiDB would
>> transparently handle such a situation, perhaps BogoUser~s should
>> simply be restricted to saving preferences into a cookie until his/her
>> e-mail address has been verified.)
>
> I think this should be another index.php option.
>
> if (!defined('REQUIRE_EMAIL_VERIFICATION')) 
> define('REQUIRE_EMAIL_VERIFICATION',false);
>
> This would go for storing users in the External DB (if allowed),
> for the EmailNotification on page changes feature and saving prefs in 
> the homepage.
>
> One might need to allow this without EMAIL_VERIFICATION.
>
> Regarding EMAIL_VERIFICATION:
>   we need another url action with the sent id as get parameter
> (e.g.: phpwiki.sf.net/demo/UserName?verify=48731984718937489312749812)
>   and we might need a table to store this pending request id.
>   or would it be enough to store the verification id in the userpage 
> metadata for this short time.?
>   as long as the verify metadata in the users homepage is present, the 
> preferences are restricted to cookies.
>
> So will need those new userpref classes:
>   CookieUserPref, HomepageUserPref, ExternalFileUserPref and 
> ExternalDbUserPref; dependent on where to read/write preferences.
>
> But on the contrary different classes where to read/write authinfo:
>   AnonUserAuth, BogoUserAuth, AdminUserAuth (questionable), 
> CookieUserAuth, HomepageUserAuth, ExternalImapUserAuth, 
> ExternalLdapUserAuth, ExternalFileUserAuth, ExternalDbUserPref.
>
> One could throw away AdminUserAuth because the Anon- and BogoUserAuth 
> class methods should check if the given username is the ADMIN_USER and 
> force a password on this attempted login. All other classes require a 
> password.
>
> Maybe we should provide a ALLOW_EMPTY_PASSWORD config option also, 
> maybe also some kind of password strength restriction policy (min 6 
> chars, ...)
>
> Ok?
> -- 
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/


Yes, I agree new user classes will have to be added for the external 
authentication. So many possibilities you suggested, it's going to take 
a while to finish that all. :)

For the first implementation of WikiUserNew, I think I'll just try to 
get it running with the basic classes (as we have now, just anon, bogo 
and admin), but also keeping in mind to leave room to be able to add 
the external auth.

Last night I thought more about the bogouser prefs "problem", I think I 
have an easy solution:

If ALLOW_BOGO_LOGIN is set:

* BogoUser cannot save preferences into the page at all (or other 
external db/backend), only cookies.
* BogoUser may enter an email address, but it will not be verified, 
because anyone can log in as that user and alter it (malicious or 
accidental).
* Once BogoUser enters a password, he is (naturally) no longer a 
BogoUser class but a PasswordUser. At this point, it does not matter if 
his email is verified or not, we let him save prefs. Provided the admin 
has not set REQUIRE_EMAIL_VERIFICATION.

If ALLOW_PASSWORD_LOGIN is set:

* If a PasswordUser deletes his password (and if ALLOW_BOGO_LOGIN is 
set), he gets a warning: "Your preferences will stored in a cookie from 
now and prefs deleted from the page. Your email address could be 
exposed to other users, so delete it if this is not what you want."
* If ALLOW_BOGO_LOGIN is NOT set, a user cannot delete his password, 
only change it. (But it depends on whether external auth allows this.)

Minimum password length is also a good idea.

Carsten