Question: Why is the InstallPassword removed? I know that it is replaced by the reset password by e-mail feature in ResetPassword.

What is the procedure to reset a password on existing TWiki sites where users removed the e-mail address? BTW, this happens quite frequently on TWiki.org with 20K registrations.

-- PTh

On coporate intranet sites the users are always going to have an address.

On the Internet sites I've installed the policy the owner dictated has in every case been that while login is free, accountability is required and bouncing e-mail addresses and removed addresses result in deletion of the account. Bouncing mail is one indicator of spammers.

A wiki may be free and open - or not, depending on its prpose and governing policy - but there is always the issue of accountability.

-- AJA

>Question: Why is the InstallPassword removed? I know that it is replaced by the reset password by e-mail feature in ResetPassword.

There's your answer.

>What is the procedure to reset a password on existing TWiki sites where users removed the e-mail address?
>BTW, this happens quite frequently on TWiki.org with 20K registrations.

If they don't have a current email address then delete the account. Having a valid email address is a prerequisite. See RegistrationAsPlugin Proposal, Step 2.

Without a valid email address, who would you accept an InstallPassword request from?

Discarded.

-- MC

Not TWiki:Codev.RemoveWriteProtectionOfUserHomePages has further ramifications.

This all makes sense for new sites. I have a practical question for existing large TWikis on the intranet such as TWiki.org. There are many home pages out of the 20K pages that have:

• E-mail obfuscated in a human readable way (user at domain dot com, user(AT)domain(DOT)com, jsmith at my company's url, a gif image, etc)
• E-mail in bold or italic (*user@domain.com*)
• E-mail hidden in HTML comments
• E-mail obfuscated twice by TWiki and user (user@domainSTOPSPAM.com.NOSPAM)
• Invalid or incomplete e-mail address (user@yahoo)
• Two or more e-mail addresses (separated by space, comma, or some comment)
• Additional text on same line ("please remove STOPSPAM")
• A combination of any of the above
• Expired e-mail addresses (many, after 7 years)
• E-mail hidden in earlier topic version (***@yahoo.com, or hidden because of spammers)
• Empty "Email" bullet
• No "Email" bullet
• Bullets converted into a TWiki table

For example, TWiki.org has 300 "Email" bullets without an @ mark.

Clearly, this can't be fixed by a script. It is also too draconian to remove all accounts that do not have a "valid" email address in the "Email" bullet. For example, some TWiki contributors do not have a machine readable "valid" email address.

If I need to fix those thousands of topics, who is going to help? A more practical solution is to offer an install password feature a la Cairo just for those sites? Any other practical way to address this issue? Does anyone have a creative idea?

-- PTh

'scuse my probable ignorance, but can't you just use the Cairo installpasswd script with those sites?

CC

That script uses:

use TWiki;
use TWiki::User;
use TWiki::User::HtPasswdUser;

Which means that I would need to have Cairo and Dakar installed in parallel. Not a good solution.

-- PTh

Just to check whether I've understood correctly: This concerns users who do have an email address for contacting PTh, but unfortunately not (or not in a parseable syntax) on their personal page. So ResetPassword fails (no email) and ChangePassword fails (no old password). Such cases can't be solved without manual intervention.

An idea: Changing ChangePassword in a way that authenticated members of the TWikiAdminGroup may leave the "Old password" field empty in the ChangePassword form would come pretty close to what I think that InstallPassword did.

-- TWiki:Main.HaraldJoerg

>An idea: Changing ChangePassword in a way that authenticated members of the TWikiAdminGroup may leave the "Old
>password" field empty in the ChangePassword form would come pretty close to what I think that InstallPassword did.

>> Without a valid email address, who would you accept an InstallPassword request from?

• RIGHT! Humungous great security hole.
  Peter, please, are you telling us that you are comnpromising the security of twiki.org by doing this? Accepting and acting on passord change requests from just anyone who mails them in? "Pleease, I'm Crawford Currie, at See-Dot@hotmailNOSPAM.co.uk, can you change my password even though I don't want anyone to know my e-mail address...." Right! -- AJA
  • What is more likely? Me mistakely installing a new password for a person in the admin group without verification, or someone cracking the password of an admin group member because the passwords have not been changed for 3 years? -- PTh

Ok. I can understand people wanting their email address hidden. Harald's idea is a good compromise, and should be easily implemented. There should be a some wordage around "Email {the administrator} if you've lost your password and your email address on your page is invalid.

-- MC

I think both is useful for public sites, an e-mail based reset and one based on generate/e-mail admin/install. For manual resets I as an admin do not want to know the password, and it should be a quick action.

-- PTh

Forgive my usual ignorance, but isn't an "admin install" (if you are using htpasswd) simply:

htpasswd .htpasswd username

which is about as quick as it gets, no?

CC

Reclassified as low.

MC

Back to Normal. There are many existing public websites where this is an issue. I can't upgrade TWiki.org to Dakar until this issue is resolved because I can't take yet an additional workload. I have several password reset requests a week, some of which have an invalid e-mail address in the home page.

Crawford: Yes, with shell login it can be done. Not as convenient as a web based interface. However, how does a user who has an invalid e-mail address in the home page generate the encrypted password in the first place? Chicken and egg problem.

-- PTh

>>An idea: Changing ChangePassword in a way that authenticated members of the
>> TWikiAdminGroup may leave the "Old password" field empty in the
>>!ChangePassword form would come pretty close to what I think that InstallPassword did.

> Harald's idea is a good compromise, and should be easily implemented.

I don't care for this to be solved (I believe its better that you delete the user) but if you want to go handing out accounts without any sort verification I suggest you implement this.

Its likely to be three lines of code: 1) make the filling in of the old password optional if you are admin 2) make the check of the old password optional 3) something in the docs.

Good luck.

MC

I am already working several hours a day on open source TWiki. If I take on this task it will delay the other things I am working on (mainly bringing Dakar docs up to the standard). Martin, you are most familiar with the registration code, any chance that you do this enhancement?

-- PTh

I think the answer to you question how does a user who has an invalid e-mail address in the home page generate the encrypted password in the first place is quite simple; they don't. A valid email address should be a precondition for a password reset, as it is in most other systems.

If they have a valid email, then the password reset process is completely automatic.

If they can't log in to edit their home page to set a valid email address, then they can still ask for a password reset by mail, and get mailed a password generated by admin (using htpasswd), with instructions to change it on receipt. There really is very little point in adding the extra layer of encryption, as http sends passwords in plain text anyway.

Here's a password setter CGI script that might work (off the top of my head, untested):

#!/usr/bin/perl
print <<'HERE';
Content-type: text/html

<html>
 <body>
  Password setting script. Sets a password for the given username. For admin use only,
  make sure your Apache server is set up so only admins can access it.<br>
  <form action="URL/OF/SCRIPT/HERE">
   Username <input name="username"><br>
   Password <input name="password"><br>
   <input type="hidden" name="action" value="set">
   <input type="submit" value="Change password">
  </form>
 </body>
</html>";
HERE
my $user = $q->param('username');
my $pw = $->param('password');
if ($q->param('set') && $user && $pw) {
    print `htpasswd -b PATH/TO/.HTPASSWD/HERE $user $pw`;
}

CC

> I am already working several hours a day on open source TWiki.
Y, we all are.

> Martin, you are most familiar with the registration code, any chance that you do this enhancement?

Peter, I offer you a deal: I will spend the time to put this feature into the distro/registration process if you reengage on the discussion on TWiki:Codev.PluginsNeedCategorizing to the point that you give it your go-ahead: I am convinced that we can restart that process with no more than a simple prefix for vertical applications. We have the rename capability, so its not a disaster if things need to change.

MC

OK, negotiating time then: I will take time to comment on TWiki:Codev.PluginsNeedCategorizing (at the cost of TWiki.org doc merge/tech writing) if you come up with a solution that allows site admins to configure TWiki to behave like Cairo for changing passwords, that is:

• offer a ResetPassword feature that generates an encrypted string to be sent to the admin
• offer a InstallPassword feature that allows admins to install an encrypted string
• hide & disable reset-password-by-mail feature (so that there is no need to lock down the user home page)

The first two points address the needs of existing sites with a large user base where many home pages do not have a valid e-mail address.

The last point is a temporary solution until we figure out a clean way to keep the home pages unlocked and allow passwords to be reset by mail. (Edinburgh)

-- PTh

AFAIK TWiki.org is the only site that wants to work this way. Is anyone else aware of any other sites that need this capability? I ask because personally I'd rather see Martin working on testing than this. But if it's a common requirement, we should do it.

CC

Assuming this change does not make it into Dakar who is going toi take the additional maintenance load on TWiki.org?

Also, it is not sufficient to ask just here, only a handful developers are watching the Bugs web.

-- PTh

Additional maintenance load? Let's think about that. At the moment, here's what happens:

1. User resets their password
2. User mails encrypted password to admin (all users)
3. Admin visits the password reset page, enters username and encrypted password
4. Admin mails back to user that their password has changed.

Is that right? Ok, my proposal above changes it to this:

1. User resets their password
2. User request gets automatically rejected because home page has no email address
3. Route 1 (most users)
   1. User sets a valid email (even if it is a use-once throwaway)
   2. User resets their password (automatic)
4. Route 2 (occasional user who is paranoid about entering an email address)
   1. User mails webmaster@twikiNOSPAM.org their password change request
   2. Admin visits the script I gave above and sets a new pass
   3. Admin mails back the new password

AFAICT, since most users go Route 1, this is a lower maintenance load.

What am I missing? Am I expecting too much from Route 1?

BTW I asked here because I expected that you would know about any other large public sites. Given our record in getting answers to this sort of question on twiki.org, I didn't see any point in asking there.

CC

With Dakar, Route 1 is only possible if you can log in as the user in question. If I can log in, I wouldn't need ResetPassword....

Compared to Route 2, Peter's preferred solution has the benefit that there's no need to mail the user's password as plain text, and Peter doesn't have to know the password at all. Given that twiki.org is using basic auth with http, and that Peter is TWiki admin, this is not a matter of security, but rather a minor act of decency: Passwords are the user's secret. More important: It can be implemented as a one-click-solution for the admin.

A Dakar InstallPassword could be driven by Dakar forms, similar to the registration process:

1. User resets password = four fields for "Wikiname", "new password", "new password confirmation", and "mail address" (needed to avoid action="mailto")
2. User submits
3. TWiki creates a mail body including a href with the complete link to the InstallPassword topic: .../bin/installpassword?user=wikiname;encpass=encrypted;mail=me@home
4. Admin klicks on this link, authenticates in his browser
5. TWiki sends a confirmation mail to the user

I agree that the problem should be a particular one for twiki.org and similar TWikis, but the number of similar TWikis would be approximately zero:

• Open to the internet
• Big number of registered users
• No "corporate" confinement, i.e. everyone can register
• Many users write very rarely or never, which increases the probability that they forget their password, or updating their mail address - or both

Given the nature of the feature - it does not require a change in the existing code and it is going to be used by very few TWiki installations - I'd suggest to implement it as an addon. In my opinion there's nothing wrong with having an addon which only twiki.org and similar huge sites are using.

If we have this as addon, we are no longer running in acute problems with the Dakar Beta timeframe: It is sufficient if it is done when twiki.org is switching to Dakar.

I'd like to see this item out of the way. I think that I'm familiar enough with Dakar's password mechanism to start implementing it. So if you would accept me as a volunteer, drop a note....

-- TWiki:Main.HaraldJoerg

Harald, I would very much welcome your contribution in this area.

-- MC

Go for it.

CC

---

TWiki:Plugins.InstallPasswordAddOn has a first version. Changing status to "Waiting for feedback" instead of "Waiting for HaraldJoerg"

-- TWiki:Main.HaraldJoerg

Thanks Harald!

I'm sure Peter is best positioned give you feedback.

-- MC

Changing status to 'closed'. Use Extension-InstallPasswordAddOn to track (BTW it should really be called "Contrib", not "AddOn").

CC