Idea for a new plugin/feature: a 'forgot my password' option

Hi,

I would appreciate to get some opinions about a 'forgot my password'
feature in Squirrelmail.

I would not like to register a SourceForge account for awhile.

If it is not acceptable to discuss this kind of issue in the list,
please, advise me.

The idea:

User register an 'alternative e-mail' in Squirrelmail 'options'.
Squirrelmail sends a 'confirmation message' to that 'alternative
e-mail' and stores a 'confirmation ticket'
---if confirmation occurs, approve 'alternative e-mail' and includes
it in user prefs
---else 'forget' the confirmation after some time (maybe a cron job to
deal with).

User tries to login and, if he/she make mistakes, a 'forgot my
password' button is displayed near of 'login' button.
---If user clicks on 'forgot my password', Squirrelmail asks for
'alternative e-mail' and checks it with user prefs.
------if it matches, resets the user password to a temporary random
password (a big one) AND send it to 'alternative e-mail' AND
---------registers a 'timeout' to that 'temporary password' (cron job again?).
------------after a T time, resets the user password to an 'random
password' (it would trigger a help desk call latter).
------elseif it does not match, just tell user that 'alternative
e-mail' does not match.

I can imagine that the 'change the password' is a difficult point to
deal of, because the number of 'backends' available to store user's
credentials.

It will be necessary to have options to enable/disable the feature and
to register/delete/change 'alternative e-mail'. The 'timeouts'
features using cron woul be plataform dependant, but I think it is
acceptable.

I thought that it is necessary to have some kind of 'protection' to
not get the feature 'abused'.

How 'complicated' is that to develop? I am not a programmer, so, I can
just 'imagine' that it is not a trivial task.

It would be nice to have this 'feature' in Squirrelmail.

Best regards,

Cássio

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----
squirrelmail-plugins mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-plugins@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins

[Derek Piazza]

How are your passwords stored?

Thanks,
Derek

casfre@... wrote:

> Hi,
>
> I would appreciate to get some opinions about a 'forgot my password'
> feature in Squirrelmail.
>
> I would not like to register a SourceForge account for awhile.
>
> If it is not acceptable to discuss this kind of issue in the list,
> please, advise me.
>
> The idea:
>
> User register an 'alternative e-mail' in Squirrelmail 'options'.
> Squirrelmail sends a 'confirmation message' to that 'alternative
> e-mail' and stores a 'confirmation ticket'
> ---if confirmation occurs, approve 'alternative e-mail' and includes
> it in user prefs
> ---else 'forget' the confirmation after some time (maybe a cron job to
> deal with).
>
> User tries to login and, if he/she make mistakes, a 'forgot my
> password' button is displayed near of 'login' button.
> ---If user clicks on 'forgot my password', Squirrelmail asks for
> 'alternative e-mail' and checks it with user prefs.
> ------if it matches, resets the user password to a temporary random
> password (a big one) AND send it to 'alternative e-mail' AND
> ---------registers a 'timeout' to that 'temporary password' (cron job again?).
> ------------after a T time, resets the user password to an 'random
> password' (it would trigger a help desk call latter).
> ------elseif it does not match, just tell user that 'alternative
> e-mail' does not match.
>
> I can imagine that the 'change the password' is a difficult point to
> deal of, because the number of 'backends' available to store user's
> credentials.
>
> It will be necessary to have options to enable/disable the feature and
> to register/delete/change 'alternative e-mail'. The 'timeouts'
> features using cron woul be plataform dependant, but I think it is
> acceptable.
>
> I thought that it is necessary to have some kind of 'protection' to
> not get the feature 'abused'.
>
> How 'complicated' is that to develop? I am not a programmer, so, I can
> just 'imagine' that it is not a trivial task.
>
> It would be nice to have this 'feature' in Squirrelmail.
>
> Best regards,
>
> Cássio
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> -----
> squirrelmail-plugins mailing list
> Posting guidelines: http://squirrelmail.org/postingguidelines
> List address: squirrelmail-plugins@...
> List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins
> List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins
>  

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----
squirrelmail-plugins mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-plugins@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins

HI,

On Sun, Aug 2, 2009 at 2:10 PM, Derek<subaruboi@...> wrote:
> How are your passwords stored?

In this case, /etc/shadow.

Thanks,

Cássio

> casfre@... wrote:
>> Hi,
>>
>> I would appreciate to get some opinions about a 'forgot my password'
>> feature in Squirrelmail.
>>
>> I would not like to register a SourceForge account for awhile.
>>
>> If it is not acceptable to discuss this kind of issue in the list,
>> please, advise me.
>>
>> The idea:
>>
>> User register an 'alternative e-mail' in Squirrelmail 'options'.
>> Squirrelmail sends a 'confirmation message' to that 'alternative
>> e-mail' and stores a 'confirmation ticket'
>> ---if confirmation occurs, approve 'alternative e-mail' and includes
>> it in user prefs
>> ---else 'forget' the confirmation after some time (maybe a cron job to
>> deal with).
>>
>> User tries to login and, if he/she make mistakes, a 'forgot my
>> password' button is displayed near of 'login' button.
>> ---If user clicks on 'forgot my password', Squirrelmail asks for
>> 'alternative e-mail' and checks it with user prefs.
>> ------if it matches, resets the user password to a temporary random
>> password (a big one) AND send it to 'alternative e-mail' AND
>> ---------registers a 'timeout' to that 'temporary password' (cron job again?).
>> ------------after a T time, resets the user password to an 'random
>> password' (it would trigger a help desk call latter).
>> ------elseif it does not match, just tell user that 'alternative
>> e-mail' does not match.
>>
>> I can imagine that the 'change the password' is a difficult point to
>> deal of, because the number of 'backends' available to store user's
>> credentials.
>>
>> It will be necessary to have options to enable/disable the feature and
>> to register/delete/change 'alternative e-mail'. The 'timeouts'
>> features using cron woul be plataform dependant, but I think it is
>> acceptable.
>>
>> I thought that it is necessary to have some kind of 'protection' to
>> not get the feature 'abused'.
>>
>> How 'complicated' is that to develop? I am not a programmer, so, I can
>> just 'imagine' that it is not a trivial task.
>>
>> It would be nice to have this 'feature' in Squirrelmail.
>>
>> Best regards,
>>
>> Cássio

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----
squirrelmail-plugins mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-plugins@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins

[Paul Lesniewski]

On 8/2/09, casfre@... <casfre@...> wrote:
> Hi,
>
> I would appreciate to get some opinions about a 'forgot my password'
> feature in Squirrelmail.
>
> I would not like to register a SourceForge account for awhile.

What's that got to do with this?

> If it is not acceptable to discuss this kind of issue in the list,
> please, advise me.

It's fine here - even appropriate...

> The idea:
>
> User register an 'alternative e-mail' in Squirrelmail 'options'.
> Squirrelmail sends a 'confirmation message' to that 'alternative
> e-mail' and stores a 'confirmation ticket'
> ---if confirmation occurs, approve 'alternative e-mail' and includes
> it in user prefs
> ---else 'forget' the confirmation after some time (maybe a cron job to
> deal with).
>
> User tries to login and, if he/she make mistakes, a 'forgot my
> password' button is displayed near of 'login' button.
> ---If user clicks on 'forgot my password', Squirrelmail asks for
> 'alternative e-mail' and checks it with user prefs.
> ------if it matches, resets the user password to a temporary random
> password (a big one) AND send it to 'alternative e-mail' AND
> ---------registers a 'timeout' to that 'temporary password' (cron job
> again?).
> ------------after a T time, resets the user password to an 'random
> password' (it would trigger a help desk call latter).
> ------elseif it does not match, just tell user that 'alternative
> e-mail' does not match.
>
> I can imagine that the 'change the password' is a difficult point to
> deal of, because the number of 'backends' available to store user's
> credentials.
>
> It will be necessary to have options to enable/disable the feature and
> to register/delete/change 'alternative e-mail'. The 'timeouts'
> features using cron woul be plataform dependant, but I think it is
> acceptable.
>
> I thought that it is necessary to have some kind of 'protection' to
> not get the feature 'abused'.
>
> How 'complicated' is that to develop? I am not a programmer, so, I can
> just 'imagine' that it is not a trivial task.
>
> It would be nice to have this 'feature' in Squirrelmail.

SquirrelMail being an IMAP *client*, it does not know anything about
how/where passwords are stored and has no integration with the MTA
(where the alternative email account confirmation would need to be
intercepted).  That is to say, this entire system could work
reasonably well, but none of it can/should/would be built into
SquirrelMail, except perhaps the link on the login page for "Forgot
your password?"  You could put a simple form in the SM options to
initially accept the alternate email, but that's the easy part.  The
rest is unrelated to SM.

--
Paul Lesniewski
SquirrelMail Team
Please support Open Source Software by donating to SquirrelMail!
http://squirrelmail.org/donate_paul_lesniewski.php

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----
squirrelmail-plugins mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-plugins@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins

On Sun, Aug 2, 2009 at 3:06 PM, Paul Lesniewski<paul@...> wrote:
> On 8/2/09, casfre@... <casfre@...> wrote:
>> Hi,
>>
>> I would appreciate to get some opinions about a 'forgot my password'
>> feature in Squirrelmail.
>>
>> I would not like to register a SourceForge account for awhile.
>
> What's that got to do with this?

Sorry, I forgot to explain the reason: before sending my message I was
reading the Squirrelmail  Tracker system and there, we need an account
to register a 'feature request'. :-)

>
>> If it is not acceptable to discuss this kind of issue in the list,
>> please, advise me.
>
> It's fine here - even appropriate...
>
>> The idea:
>>
>> User register an 'alternative e-mail' in Squirrelmail 'options'.
>> Squirrelmail sends a 'confirmation message' to that 'alternative
>> e-mail' and stores a 'confirmation ticket'
>> ---if confirmation occurs, approve 'alternative e-mail' and includes
>> it in user prefs
>> ---else 'forget' the confirmation after some time (maybe a cron job to
>> deal with).
>>
>> User tries to login and, if he/she make mistakes, a 'forgot my
>> password' button is displayed near of 'login' button.
>> ---If user clicks on 'forgot my password', Squirrelmail asks for
>> 'alternative e-mail' and checks it with user prefs.
>> ------if it matches, resets the user password to a temporary random
>> password (a big one) AND send it to 'alternative e-mail' AND
>> ---------registers a 'timeout' to that 'temporary password' (cron job
>> again?).
>> ------------after a T time, resets the user password to an 'random
>> password' (it would trigger a help desk call latter).
>> ------elseif it does not match, just tell user that 'alternative
>> e-mail' does not match.
>>
>> I can imagine that the 'change the password' is a difficult point to
>> deal of, because the number of 'backends' available to store user's
>> credentials.
>>
>> It will be necessary to have options to enable/disable the feature and
>> to register/delete/change 'alternative e-mail'. The 'timeouts'
>> features using cron woul be plataform dependant, but I think it is
>> acceptable.
>>
>> I thought that it is necessary to have some kind of 'protection' to
>> not get the feature 'abused'.
>>
>> How 'complicated' is that to develop? I am not a programmer, so, I can
>> just 'imagine' that it is not a trivial task.
>>
>> It would be nice to have this 'feature' in Squirrelmail.
>
> SquirrelMail being an IMAP *client*, it does not know anything about
> how/where passwords are stored and has no integration with the MTA
> (where the alternative email account confirmation would need to be
> intercepted).  That is to say, this entire system could work
> reasonably well, but none of it can/should/would be built into
> SquirrelMail, except perhaps the link on the login page for "Forgot
> your password?"  You could put a simple form in the SM options to
> initially accept the alternate email, but that's the easy part.  The
> rest is unrelated to SM.

Yes, I thought about that. Actually, I am trying to see how and if the
feature can be, at least, integrated with Squirrelmail (the form you
suggested, for example).

About the 'alternative email account confirmation', I was thinking
about using some kind of 'clickable ticket', with a 'special' URL. The
confirmation would not be intercepted by email, but using the access
to that special URL. It would be something like:
https://host.some.domain/confirmation?ticket=j2YDIUYHln0XEFi3dSg1skDwcsoQfz1pzXMVPxab18e.
This URL (unique ticket number) would be generated in the server and
sent to 'alternative e-mail', maybe together with 'temporary
password'.

About the password changing, I was thinking about some kind of
integration with some of the 'change_password' plugins. For example,
if I use /etc/shadow and change_pass with poppassd so, this would be
the mechanism to do that password modification. In the same way, if
someone else uses, for example, LDAP password so, the integration
would be with that specific 'change_pass' plugin.

To send the URL to the 'alternative e-mail', I thought it could be
arranged in a similar way squirrel_logger do to send messages.

Alternatively, I thought, for example, that a Squirrelmail plugin
could deal with 'register/change/delete' 'alternative e-mail', with
the 'forgot password' button and whith the form to get user
information when he/she forgots the password. For example, at each
'user request to recover password', Squirrelmail just stores a file,
similar to lockout_plugin, with information got from user and 'local
procedures' take care of the rest of the process.

I really appreciate your attention. :-)

Best regards,

Cássio

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----
squirrelmail-plugins mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-plugins@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins

[Paul Lesniewski]

On 8/2/09, casfre@... <casfre@...> wrote:

> On Sun, Aug 2, 2009 at 3:06 PM, Paul Lesniewski<paul@...>
> wrote:
>> On 8/2/09, casfre@... <casfre@...> wrote:
>>> Hi,
>>>
>>> I would appreciate to get some opinions about a 'forgot my password'
>>> feature in Squirrelmail.
>>>
>>> I would not like to register a SourceForge account for awhile.
>>
>> What's that got to do with this?
>
> Sorry, I forgot to explain the reason: before sending my message I was
> reading the Squirrelmail  Tracker system and there, we need an account
> to register a 'feature request'. :-)

I see.  Well, keep in mind tracker items are a little less likely to
get lost in the shuffle.

>>> If it is not acceptable to discuss this kind of issue in the list,
>>> please, advise me.
>>
>> It's fine here - even appropriate...
>>
>>> The idea:
>>>
>>> User register an 'alternative e-mail' in Squirrelmail 'options'.
>>> Squirrelmail sends a 'confirmation message' to that 'alternative
>>> e-mail' and stores a 'confirmation ticket'
>>> ---if confirmation occurs, approve 'alternative e-mail' and includes
>>> it in user prefs
>>> ---else 'forget' the confirmation after some time (maybe a cron job to
>>> deal with).
>>>
>>> User tries to login and, if he/she make mistakes, a 'forgot my
>>> password' button is displayed near of 'login' button.
>>> ---If user clicks on 'forgot my password', Squirrelmail asks for
>>> 'alternative e-mail' and checks it with user prefs.
>>> ------if it matches, resets the user password to a temporary random
>>> password (a big one) AND send it to 'alternative e-mail' AND
>>> ---------registers a 'timeout' to that 'temporary password' (cron job
>>> again?).
>>> ------------after a T time, resets the user password to an 'random
>>> password' (it would trigger a help desk call latter).
>>> ------elseif it does not match, just tell user that 'alternative
>>> e-mail' does not match.
>>>
>>> I can imagine that the 'change the password' is a difficult point to
>>> deal of, because the number of 'backends' available to store user's
>>> credentials.
>>>
>>> It will be necessary to have options to enable/disable the feature and
>>> to register/delete/change 'alternative e-mail'. The 'timeouts'
>>> features using cron woul be plataform dependant, but I think it is
>>> acceptable.
>>>
>>> I thought that it is necessary to have some kind of 'protection' to
>>> not get the feature 'abused'.
>>>
>>> How 'complicated' is that to develop? I am not a programmer, so, I can
>>> just 'imagine' that it is not a trivial task.
>>>
>>> It would be nice to have this 'feature' in Squirrelmail.
>>
>> SquirrelMail being an IMAP *client*, it does not know anything about
>> how/where passwords are stored and has no integration with the MTA
>> (where the alternative email account confirmation would need to be
>> intercepted).  That is to say, this entire system could work
>> reasonably well, but none of it can/should/would be built into
>> SquirrelMail, except perhaps the link on the login page for "Forgot
>> your password?"  You could put a simple form in the SM options to
>> initially accept the alternate email, but that's the easy part.  The
>> rest is unrelated to SM.
>
> Yes, I thought about that. Actually, I am trying to see how and if the
> feature can be, at least, integrated with Squirrelmail (the form you
> suggested, for example).
>
> About the 'alternative email account confirmation', I was thinking
> about using some kind of 'clickable ticket', with a 'special' URL. The
> confirmation would not be intercepted by email, but using the access
> to that special URL. It would be something like:
> https://host.some.domain/confirmation?ticket=j2YDIUYHln0XEFi3dSg1skDwcsoQfz1pzXMVPxab18e.

If you try to do it completely within SM, the link would have to go to
the SM installation, and to click on the link, the user would need to
already be logged into the SM account (perhaps not a bad thing).  Or
you could provide a PHP file to be placed elsewhere in the
administrator's system/website.  If placed outside SM, other issues
might arise if that script tries to interface with SM functions and
data stores.

Alternately (or in addition), you can just send a code to that other
email account and provide a place in SM to input the code to activate
the use of that other email address.

> This URL (unique ticket number) would be generated in the server and
> sent to 'alternative e-mail', maybe together with 'temporary
> password'.

I don't see the need for any password here.

> About the password changing, I was thinking about some kind of
> integration with some of the 'change_password' plugins. For example,
> if I use /etc/shadow and change_pass with poppassd so, this would be
> the mechanism to do that password modification. In the same way, if
> someone else uses, for example, LDAP password so, the integration
> would be with that specific 'change_pass' plugin.

The password plugins don't have a standardized API for this, and even
the 1.5 change_password plugin doesn't provide for this kind of thing.
 But yes, you could do this with some of your own custom code.

The bigger problem is what do you do to stop an attacker from
inputting random usernames and clicking the "forgot" link?  They could
reset anyone's password at will.  If you want to, you could try to
figure out a time limit for the new password (ah, I see this is what
you originally explained), but then you have to store passwords in SM
and it just gets more and more complicated and more risky from a
security standpoint.  Data accessible to SM is often accessible to the
whole web server.  Measures can be taken to lessen this risk, but,
depending on the environment, this is not insignificant.

> To send the URL to the 'alternative e-mail', I thought it could be
> arranged in a similar way squirrel_logger do to send messages.

When an email with the reset password is sent, it's in plain text, and
that's another security concern.

> Alternatively, I thought, for example, that a Squirrelmail plugin
> could deal with 'register/change/delete' 'alternative e-mail', with
> the 'forgot password' button and whith the form to get user
> information when he/she forgots the password. For example, at each
> 'user request to recover password', Squirrelmail just stores a file,
> similar to lockout_plugin, with information got from user and 'local
> procedures' take care of the rest of the process.

You're right, more of this can be integrated into SM than I originally
thought, but it's still complex and risky.

> I really appreciate your attention. :-)



--
Paul Lesniewski
SquirrelMail Team
Please support Open Source Software by donating to SquirrelMail!
http://squirrelmail.org/donate_paul_lesniewski.php

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----
squirrelmail-plugins mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-plugins@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins

Sorry for taking so long to answer.

On Mon, Aug 3, 2009 at 5:57 PM, Paul Lesniewski<paul@...> wrote:

> On 8/2/09, casfre@... <casfre@...> wrote:
>> On Sun, Aug 2, 2009 at 3:06 PM, Paul Lesniewski<paul@...>
>> wrote:
>>> On 8/2/09, casfre@... <casfre@...> wrote:
>>>> Hi,
>>>>
>>>> I would appreciate to get some opinions about a 'forgot my password'
>>>> feature in Squirrelmail.
>>>>
>>>> I would not like to register a SourceForge account for awhile.
>>>
>>> What's that got to do with this?
>>
>> Sorry, I forgot to explain the reason: before sending my message I was
>> reading the Squirrelmail  Tracker system and there, we need an account
>> to register a 'feature request'. :-)
>
> I see.  Well, keep in mind tracker items are a little less likely to
> get lost in the shuffle.
>
>>>> If it is not acceptable to discuss this kind of issue in the list,
>>>> please, advise me.
>>>
>>> It's fine here - even appropriate...
>>>
>>>> The idea:
>>>>
>>>> User register an 'alternative e-mail' in Squirrelmail 'options'.
>>>> Squirrelmail sends a 'confirmation message' to that 'alternative
>>>> e-mail' and stores a 'confirmation ticket'
>>>> ---if confirmation occurs, approve 'alternative e-mail' and includes
>>>> it in user prefs
>>>> ---else 'forget' the confirmation after some time (maybe a cron job to
>>>> deal with).
>>>>
>>>> User tries to login and, if he/she make mistakes, a 'forgot my
>>>> password' button is displayed near of 'login' button.
>>>> ---If user clicks on 'forgot my password', Squirrelmail asks for
>>>> 'alternative e-mail' and checks it with user prefs.
>>>> ------if it matches, resets the user password to a temporary random
>>>> password (a big one) AND send it to 'alternative e-mail' AND
>>>> ---------registers a 'timeout' to that 'temporary password' (cron job
>>>> again?).
>>>> ------------after a T time, resets the user password to an 'random
>>>> password' (it would trigger a help desk call latter).
>>>> ------elseif it does not match, just tell user that 'alternative
>>>> e-mail' does not match.
>>>>
>>>> I can imagine that the 'change the password' is a difficult point to
>>>> deal of, because the number of 'backends' available to store user's
>>>> credentials.
>>>>
>>>> It will be necessary to have options to enable/disable the feature and
>>>> to register/delete/change 'alternative e-mail'. The 'timeouts'
>>>> features using cron woul be plataform dependant, but I think it is
>>>> acceptable.
>>>>
>>>> I thought that it is necessary to have some kind of 'protection' to
>>>> not get the feature 'abused'.
>>>>
>>>> How 'complicated' is that to develop? I am not a programmer, so, I can
>>>> just 'imagine' that it is not a trivial task.
>>>>
>>>> It would be nice to have this 'feature' in Squirrelmail.
>>>
>>> SquirrelMail being an IMAP *client*, it does not know anything about
>>> how/where passwords are stored and has no integration with the MTA
>>> (where the alternative email account confirmation would need to be
>>> intercepted).  That is to say, this entire system could work
>>> reasonably well, but none of it can/should/would be built into
>>> SquirrelMail, except perhaps the link on the login page for "Forgot
>>> your password?"  You could put a simple form in the SM options to
>>> initially accept the alternate email, but that's the easy part.  The
>>> rest is unrelated to SM.
>>
>> Yes, I thought about that. Actually, I am trying to see how and if the
>> feature can be, at least, integrated with Squirrelmail (the form you
>> suggested, for example).
>>
>> About the 'alternative email account confirmation', I was thinking
>> about using some kind of 'clickable ticket', with a 'special' URL. The
>> confirmation would not be intercepted by email, but using the access
>> to that special URL. It would be something like:
>> https://host.some.domain/confirmation?ticket=j2YDIUYHln0XEFi3dSg1skDwcsoQfz1pzXMVPxab18e.
>
> If you try to do it completely within SM, the link would have to go to
> the SM installation, and to click on the link, the user would need to
> already be logged into the SM account (perhaps not a bad thing).

I see, but user can't logs in, because he/she forgot the password.

>  Or you could provide a PHP file to be placed elsewhere in the
> administrator's system/website.  If placed outside SM, other issues
> might arise if that script tries to interface with SM functions and
> data stores.
>
> Alternately (or in addition), you can just send a code to that other
> email account and provide a place in SM to input the code to activate
> the use of that other email address.

Yes, the integration with Squirrelmail become more complicated as we
think about the possibilities. :-)

>> This URL (unique ticket number) would be generated in the server and
>> sent to 'alternative e-mail', maybe together with 'temporary
>> password'.
>
> I don't see the need for any password here.

I was thinking about something like "input 'alternative e-mail', click
forgot password, receive the link, click on the link, receive the temp
password".  This way, user could use the 'normal' Squirrelmail login
page.

>> About the password changing, I was thinking about some kind of
>> integration with some of the 'change_password' plugins. For example,
>> if I use /etc/shadow and change_pass with poppassd so, this would be
>> the mechanism to do that password modification. In the same way, if
>> someone else uses, for example, LDAP password so, the integration
>> would be with that specific 'change_pass' plugin.
>
> The password plugins don't have a standardized API for this, and even
> the 1.5 change_password plugin doesn't provide for this kind of thing.
> But yes, you could do this with some of your own custom code.

Hummm. I see.

> The bigger problem is what do you do to stop an attacker from
> inputting random usernames and clicking the "forgot" link?  They could
> reset anyone's password at will.  If you want to, you could try to
> figure out a time limit for the new password (ah, I see this is what
> you originally explained), but then you have to store passwords in SM
> and it just gets more and more complicated and more risky from a
> security standpoint.  Data accessible to SM is often accessible to the
> whole web server.  Measures can be taken to lessen this risk, but,
> depending on the environment, this is not insignificant.

Yes, I agree, security is one of my main concerns. I always think "how
I will stop abusers 'clicking' on 'forgot password' button?".

In this case, user will not input the 'username' (or it could be asked
to), but just 'alternative e-mail'. A local procedure would search for
that 'alternative e-mail' and find the 'local username'. If it
matches, procedure continues as we have discussed, if not, no password
is sent or changed. For example, local user 'joe' registers
alternative e-mail as 'joealternative@...'. Is
'joe' forgot his password,  he clicks on 'forgot my password', inputs
'joealternative@...', local procedure check if it
matches and, so, it knows what 'local' password is to be reset.

Anyway, potentially, for every compromised 'alternative e-mail', an
attacker would be capable to gain access to our users accounts.

Actually, I have thought even about a semi-automatic solution: human
talking to human and 'matching' some shared secret. I mean, users
choose to store (in users.pref, for example) some 'a shared secret we
know' and, if he/she can reproduce the secret to help desk (by phone,
in this case), so we give him/her a temp password. But, this model has
a lot of 'holes' too. And user can forget the 'share secret' too. :-)

I have also thought about Yubikey (or similar), but users must buy the
hardware, so, one more problem and, if I understood correctly, even
with Yubikey user needs to remember a password.

>> To send the URL to the 'alternative e-mail', I thought it could be
>> arranged in a similar way squirrel_logger do to send messages.
>
> When an email with the reset password is sent, it's in plain text, and
> that's another security concern.

Yes, another 'hole'. This password is temporary, but it will be there,
clear text, for some time.

>> Alternatively, I thought, for example, that a Squirrelmail plugin
>> could deal with 'register/change/delete' 'alternative e-mail', with
>> the 'forgot password' button and whith the form to get user
>> information when he/she forgots the password. For example, at each
>> 'user request to recover password', Squirrelmail just stores a file,
>> similar to lockout_plugin, with information got from user and 'local
>> procedures' take care of the rest of the process.
>
> You're right, more of this can be integrated into SM than I originally
> thought, but it's still complex and risky.

Actually, with your considerations, I see that integration is more
complex than it appears at the beginning.


Thank you.

Best regards

Cássio

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----
squirrelmail-plugins mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-plugins@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins

[Paul Lesniewski]

>>>>> I would appreciate to get some opinions about a 'forgot my password'
>>>>> feature in Squirrelmail.
>>>>>
>>>>> I would not like to register a SourceForge account for awhile.
>>>>
>>>> What's that got to do with this?
>>>
>>> Sorry, I forgot to explain the reason: before sending my message I was
>>> reading the Squirrelmail  Tracker system and there, we need an account
>>> to register a 'feature request'. :-)
>>
>> I see.  Well, keep in mind tracker items are a little less likely to
>> get lost in the shuffle.
>>
>>>>> If it is not acceptable to discuss this kind of issue in the list,
>>>>> please, advise me.
>>>>
>>>> It's fine here - even appropriate...
>>>>
>>>>> The idea:
>>>>>
>>>>> User register an 'alternative e-mail' in Squirrelmail 'options'.
>>>>> Squirrelmail sends a 'confirmation message' to that 'alternative
>>>>> e-mail' and stores a 'confirmation ticket'
>>>>> ---if confirmation occurs, approve 'alternative e-mail' and includes
>>>>> it in user prefs
>>>>> ---else 'forget' the confirmation after some time (maybe a cron job to
>>>>> deal with).
>>>>>
>>>>> User tries to login and, if he/she make mistakes, a 'forgot my
>>>>> password' button is displayed near of 'login' button.
>>>>> ---If user clicks on 'forgot my password', Squirrelmail asks for
>>>>> 'alternative e-mail' and checks it with user prefs.
>>>>> ------if it matches, resets the user password to a temporary random
>>>>> password (a big one) AND send it to 'alternative e-mail' AND
>>>>> ---------registers a 'timeout' to that 'temporary password' (cron job
>>>>> again?).
>>>>> ------------after a T time, resets the user password to an 'random
>>>>> password' (it would trigger a help desk call latter).
>>>>> ------elseif it does not match, just tell user that 'alternative
>>>>> e-mail' does not match.
>>>>>
>>>>> I can imagine that the 'change the password' is a difficult point to
>>>>> deal of, because the number of 'backends' available to store user's
>>>>> credentials.
>>>>>
>>>>> It will be necessary to have options to enable/disable the feature and
>>>>> to register/delete/change 'alternative e-mail'. The 'timeouts'
>>>>> features using cron woul be plataform dependant, but I think it is
>>>>> acceptable.
>>>>>
>>>>> I thought that it is necessary to have some kind of 'protection' to
>>>>> not get the feature 'abused'.
>>>>>
>>>>> How 'complicated' is that to develop? I am not a programmer, so, I can
>>>>> just 'imagine' that it is not a trivial task.
>>>>>
>>>>> It would be nice to have this 'feature' in Squirrelmail.
>>>>
>>>> SquirrelMail being an IMAP *client*, it does not know anything about
>>>> how/where passwords are stored and has no integration with the MTA
>>>> (where the alternative email account confirmation would need to be
>>>> intercepted).  That is to say, this entire system could work
>>>> reasonably well, but none of it can/should/would be built into
>>>> SquirrelMail, except perhaps the link on the login page for "Forgot
>>>> your password?"  You could put a simple form in the SM options to
>>>> initially accept the alternate email, but that's the easy part.  The
>>>> rest is unrelated to SM.
>>>
>>> Yes, I thought about that. Actually, I am trying to see how and if the
>>> feature can be, at least, integrated with Squirrelmail (the form you
>>> suggested, for example).
>>>
>>> About the 'alternative email account confirmation', I was thinking
>>> about using some kind of 'clickable ticket', with a 'special' URL. The
>>> confirmation would not be intercepted by email, but using the access
>>> to that special URL. It would be something like:
>>> https://host.some.domain/confirmation?ticket=j2YDIUYHln0XEFi3dSg1skDwcsoQfz1pzXMVPxab18e.
>>
>> If you try to do it completely within SM, the link would have to go to
>> the SM installation, and to click on the link, the user would need to
>> already be logged into the SM account (perhaps not a bad thing).
>
> I see, but user can't logs in, because he/she forgot the password.

Not when adding the secondary/external email account.  If they'd
forgotten it then, before the other email address has been activated,
this whole system is of no use anyway.

>>  Or you could provide a PHP file to be placed elsewhere in the
>> administrator's system/website.  If placed outside SM, other issues
>> might arise if that script tries to interface with SM functions and
>> data stores.
>>
>> Alternately (or in addition), you can just send a code to that other
>> email account and provide a place in SM to input the code to activate
>> the use of that other email address.
>
> Yes, the integration with Squirrelmail become more complicated as we
> think about the possibilities. :-)
>
>>> This URL (unique ticket number) would be generated in the server and
>>> sent to 'alternative e-mail', maybe together with 'temporary
>>> password'.
>>
>> I don't see the need for any password here.
>
> I was thinking about something like "input 'alternative e-mail', click
> forgot password, receive the link, click on the link, receive the temp
> password".  This way, user could use the 'normal' Squirrelmail login
> page.

Are you suggesting that the login screen would contain a text input
for the email address where the password reset code would be sent?
That's a Bad Idea.  It will immediately be used for attackers to
(easily) steal your user accounts.

>>> About the password changing, I was thinking about some kind of
>>> integration with some of the 'change_password' plugins. For example,
>>> if I use /etc/shadow and change_pass with poppassd so, this would be
>>> the mechanism to do that password modification. In the same way, if
>>> someone else uses, for example, LDAP password so, the integration
>>> would be with that specific 'change_pass' plugin.
>>
>> The password plugins don't have a standardized API for this, and even
>> the 1.5 change_password plugin doesn't provide for this kind of thing.
>> But yes, you could do this with some of your own custom code.
>
> Hummm. I see.
>
>> The bigger problem is what do you do to stop an attacker from
>> inputting random usernames and clicking the "forgot" link?  They could
>> reset anyone's password at will.  If you want to, you could try to
>> figure out a time limit for the new password (ah, I see this is what
>> you originally explained), but then you have to store passwords in SM
>> and it just gets more and more complicated and more risky from a
>> security standpoint.  Data accessible to SM is often accessible to the
>> whole web server.  Measures can be taken to lessen this risk, but,
>> depending on the environment, this is not insignificant.
>
> Yes, I agree, security is one of my main concerns. I always think "how
> I will stop abusers 'clicking' on 'forgot password' button?".
>
> In this case, user will not input the 'username' (or it could be asked
> to), but just 'alternative e-mail'. A local procedure would search for
> that 'alternative e-mail' and find the 'local username'.

I see.  But what if one user with several accounts uses the same
secondary email address?

> If it
> matches, procedure continues as we have discussed, if not, no password
> is sent or changed. For example, local user 'joe' registers
> alternative e-mail as 'joealternative@...'. Is
> 'joe' forgot his password,  he clicks on 'forgot my password', inputs
> 'joealternative@...', local procedure check if it
> matches and, so, it knows what 'local' password is to be reset.

You could also do things like establish some security questions they
have to answer.

You can also have a page where the user can go to select their new
password (instead of a random one being assigned) - they'd need the
code sent to them in the email to their other account to be able to
access this page.

> Anyway, potentially, for every compromised 'alternative e-mail', an
> attacker would be capable to gain access to our users accounts.

So specifying username AND email address would help alleviate that a
little bit.  Adding security questions can help even more.

> Actually, I have thought even about a semi-automatic solution: human
> talking to human and 'matching' some shared secret. I mean, users
> choose to store (in users.pref, for example) some 'a shared secret we
> know' and, if he/she can reproduce the secret to help desk (by phone,
> in this case), so we give him/her a temp password. But, this model has
> a lot of 'holes' too. And user can forget the 'share secret' too. :-)
>
> I have also thought about Yubikey (or similar), but users must buy the
> hardware, so, one more problem and, if I understood correctly, even
> with Yubikey user needs to remember a password.

See Swekey too.  Purchases of Swekey benefit SquirrelMail and they
seem more FOSS-friendly from what I can tell.

http://squirrelmail.org/plugin_view.php?id=270

>>> To send the URL to the 'alternative e-mail', I thought it could be
>>> arranged in a similar way squirrel_logger do to send messages.
>>
>> When an email with the reset password is sent, it's in plain text, and
>> that's another security concern.
>
> Yes, another 'hole'. This password is temporary, but it will be there,
> clear text, for some time.
>
>>> Alternatively, I thought, for example, that a Squirrelmail plugin
>>> could deal with 'register/change/delete' 'alternative e-mail', with
>>> the 'forgot password' button and whith the form to get user
>>> information when he/she forgots the password. For example, at each
>>> 'user request to recover password', Squirrelmail just stores a file,
>>> similar to lockout_plugin, with information got from user and 'local
>>> procedures' take care of the rest of the process.
>>
>> You're right, more of this can be integrated into SM than I originally
>> thought, but it's still complex and risky.
>
> Actually, with your considerations, I see that integration is more
> complex than it appears at the beginning.

--
Paul Lesniewski
SquirrelMail Team
Please support Open Source Software by donating to SquirrelMail!
http://squirrelmail.org/donate_paul_lesniewski.php

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----
squirrelmail-plugins mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-plugins@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins

On Thu, Aug 6, 2009 at 4:29 AM, Paul Lesniewski<paul@...> wrote:

>>>>>> I would appreciate to get some opinions about a 'forgot my password'
>>>>>> feature in Squirrelmail.
>>>>>>
>>>>>> I would not like to register a SourceForge account for awhile.
>>>>>
>>>>> What's that got to do with this?
>>>>
>>>> Sorry, I forgot to explain the reason: before sending my message I was
>>>> reading the Squirrelmail  Tracker system and there, we need an account
>>>> to register a 'feature request'. :-)
>>>
>>> I see.  Well, keep in mind tracker items are a little less likely to
>>> get lost in the shuffle.
>>>
>>>>>> If it is not acceptable to discuss this kind of issue in the list,
>>>>>> please, advise me.
>>>>>
>>>>> It's fine here - even appropriate...
>>>>>
>>>>>> The idea:
>>>>>>
>>>>>> User register an 'alternative e-mail' in Squirrelmail 'options'.
>>>>>> Squirrelmail sends a 'confirmation message' to that 'alternative
>>>>>> e-mail' and stores a 'confirmation ticket'
>>>>>> ---if confirmation occurs, approve 'alternative e-mail' and includes
>>>>>> it in user prefs
>>>>>> ---else 'forget' the confirmation after some time (maybe a cron job to
>>>>>> deal with).
>>>>>>
>>>>>> User tries to login and, if he/she make mistakes, a 'forgot my
>>>>>> password' button is displayed near of 'login' button.
>>>>>> ---If user clicks on 'forgot my password', Squirrelmail asks for
>>>>>> 'alternative e-mail' and checks it with user prefs.
>>>>>> ------if it matches, resets the user password to a temporary random
>>>>>> password (a big one) AND send it to 'alternative e-mail' AND
>>>>>> ---------registers a 'timeout' to that 'temporary password' (cron job
>>>>>> again?).
>>>>>> ------------after a T time, resets the user password to an 'random
>>>>>> password' (it would trigger a help desk call latter).
>>>>>> ------elseif it does not match, just tell user that 'alternative
>>>>>> e-mail' does not match.
>>>>>>
>>>>>> I can imagine that the 'change the password' is a difficult point to
>>>>>> deal of, because the number of 'backends' available to store user's
>>>>>> credentials.
>>>>>>
>>>>>> It will be necessary to have options to enable/disable the feature and
>>>>>> to register/delete/change 'alternative e-mail'. The 'timeouts'
>>>>>> features using cron woul be plataform dependant, but I think it is
>>>>>> acceptable.
>>>>>>
>>>>>> I thought that it is necessary to have some kind of 'protection' to
>>>>>> not get the feature 'abused'.
>>>>>>
>>>>>> How 'complicated' is that to develop? I am not a programmer, so, I can
>>>>>> just 'imagine' that it is not a trivial task.
>>>>>>
>>>>>> It would be nice to have this 'feature' in Squirrelmail.
>>>>>
>>>>> SquirrelMail being an IMAP *client*, it does not know anything about
>>>>> how/where passwords are stored and has no integration with the MTA
>>>>> (where the alternative email account confirmation would need to be
>>>>> intercepted).  That is to say, this entire system could work
>>>>> reasonably well, but none of it can/should/would be built into
>>>>> SquirrelMail, except perhaps the link on the login page for "Forgot
>>>>> your password?"  You could put a simple form in the SM options to
>>>>> initially accept the alternate email, but that's the easy part.  The
>>>>> rest is unrelated to SM.
>>>>
>>>> Yes, I thought about that. Actually, I am trying to see how and if the
>>>> feature can be, at least, integrated with Squirrelmail (the form you
>>>> suggested, for example).
>>>>
>>>> About the 'alternative email account confirmation', I was thinking
>>>> about using some kind of 'clickable ticket', with a 'special' URL. The
>>>> confirmation would not be intercepted by email, but using the access
>>>> to that special URL. It would be something like:
>>>> https://host.some.domain/confirmation?ticket=j2YDIUYHln0XEFi3dSg1skDwcsoQfz1pzXMVPxab18e.
>>>
>>> If you try to do it completely within SM, the link would have to go to
>>> the SM installation, and to click on the link, the user would need to
>>> already be logged into the SM account (perhaps not a bad thing).
>>
>> I see, but user can't logs in, because he/she forgot the password.
>
> Not when adding the secondary/external email account.  If they'd
> forgotten it then, before the other email address has been activated,
> this whole system is of no use anyway.

Oh, I see. Sure, to register 'alternative e-mail', being logged is mandatory.

>>>  Or you could provide a PHP file to be placed elsewhere in the
>>> administrator's system/website.  If placed outside SM, other issues
>>> might arise if that script tries to interface with SM functions and
>>> data stores.
>>>
>>> Alternately (or in addition), you can just send a code to that other
>>> email account and provide a place in SM to input the code to activate
>>> the use of that other email address.
>>
>> Yes, the integration with Squirrelmail become more complicated as we
>> think about the possibilities. :-)
>>
>>>> This URL (unique ticket number) would be generated in the server and
>>>> sent to 'alternative e-mail', maybe together with 'temporary
>>>> password'.
>>>
>>> I don't see the need for any password here.
>>
>> I was thinking about something like "input 'alternative e-mail', click
>> forgot password, receive the link, click on the link, receive the temp
>> password".  This way, user could use the 'normal' Squirrelmail login
>> page.
>
> Are you suggesting that the login screen would contain a text input
> for the email address where the password reset code would be sent?
> That's a Bad Idea.  It will immediately be used for attackers to
> (easily) steal your user accounts.

Just if typed 'alternative e-mail' matches a register in local tables
(that alternative e-mail registered before, by user).

>>>> About the password changing, I was thinking about some kind of
>>>> integration with some of the 'change_password' plugins. For example,
>>>> if I use /etc/shadow and change_pass with poppassd so, this would be
>>>> the mechanism to do that password modification. In the same way, if
>>>> someone else uses, for example, LDAP password so, the integration
>>>> would be with that specific 'change_pass' plugin.
>>>
>>> The password plugins don't have a standardized API for this, and even
>>> the 1.5 change_password plugin doesn't provide for this kind of thing.
>>> But yes, you could do this with some of your own custom code.
>>
>> Hummm. I see.
>>
>>> The bigger problem is what do you do to stop an attacker from
>>> inputting random usernames and clicking the "forgot" link?  They could
>>> reset anyone's password at will.  If you want to, you could try to
>>> figure out a time limit for the new password (ah, I see this is what
>>> you originally explained), but then you have to store passwords in SM
>>> and it just gets more and more complicated and more risky from a
>>> security standpoint.  Data accessible to SM is often accessible to the
>>> whole web server.  Measures can be taken to lessen this risk, but,
>>> depending on the environment, this is not insignificant.
>>
>> Yes, I agree, security is one of my main concerns. I always think "how
>> I will stop abusers 'clicking' on 'forgot password' button?".
>>
>> In this case, user will not input the 'username' (or it could be asked
>> to), but just 'alternative e-mail'. A local procedure would search for
>> that 'alternative e-mail' and find the 'local username'.
>
> I see.  But what if one user with several accounts uses the same
> secondary email address?

Woops, you're right. My bad. If it is a possibility (and it can
happens) we need to know 'who is the user'. In this case, the user can
not forget the 'username'. :-) Anyway we really need two input fields
in the 'forgot password' page. :-)

>
>> If it
>> matches, procedure continues as we have discussed, if not, no password
>> is sent or changed. For example, local user 'joe' registers
>> alternative e-mail as 'joealternative@...'. Is
>> 'joe' forgot his password,  he clicks on 'forgot my password', inputs
>> 'joealternative@...', local procedure check if it
>> matches and, so, it knows what 'local' password is to be reset.
>
> You could also do things like establish some security questions they
> have to answer.

Good idea: a 'challenge'. :-) Or do you thought about having a
'security question', registered before, by the user (one for each
user)?

> You can also have a page where the user can go to select their new
> password (instead of a random one being assigned) - they'd need the
> code sent to them in the email to their other account to be able to
> access this page.

Good idea. A code to access a page where the user can 'reset' its
password, and this code can expire. It would help to protect the
system from abusers and there would be no 'clear text password'.

Could be something like: I forgot my password, click on 'forgot my
password' button (similar to 'login' button), input 'username' and
'alternative e-mail', system generates and send 'the code'  [ and 'a
challenge' ], user access 'change password' page [ maybe the URL could
be 'temporary' ],  input code (a big one), input username and
alternative e-mail again, system checks if 'code' is still 'active' [
verifying expiration time], system checks if username/alternative
e-mail/code is valid, user changes its password, system destroys [
temporary urls ] the code.

>
>> Anyway, potentially, for every compromised 'alternative e-mail', an
>> attacker would be capable to gain access to our users accounts.
>
> So specifying username AND email address would help alleviate that a
> little bit.  Adding security questions can help even more.

Sure, security must be mandatory, from the beginning. Good idea. :-)
Anyway, we would still have a way to reset a password, in our systems,
based on another system credentials.

I was wondering that the system could send an e-mail, to the local
user e-mail address, to warn him that he (or somebody) had changed its
password.

>
>> Actually, I have thought even about a semi-automatic solution: human
>> talking to human and 'matching' some shared secret. I mean, users
>> choose to store (in users.pref, for example) some 'a shared secret we
>> know' and, if he/she can reproduce the secret to help desk (by phone,
>> in this case), so we give him/her a temp password. But, this model has
>> a lot of 'holes' too. And user can forget the 'share secret' too. :-)
>>
>> I have also thought about Yubikey (or similar), but users must buy the
>> hardware, so, one more problem and, if I understood correctly, even
>> with Yubikey user needs to remember a password.
>
> See Swekey too.  Purchases of Swekey benefit SquirrelMail and they
> seem more FOSS-friendly from what I can tell.
>
> http://squirrelmail.org/plugin_view.php?id=270
>

Great. Thank you. Actually I remembered I had already read about Swekey too. :-)

I still think this idea is good, but I also noticed that it is more
complicated than it appears to be. :-)

Really thank you for your attention and feedback. :-)

Best regards.

>>>> To send the URL to the 'alternative e-mail', I thought it could be
>>>> arranged in a similar way squirrel_logger do to send messages.
>>>
>>> When an email with the reset password is sent, it's in plain text, and
>>> that's another security concern.
>>
>> Yes, another 'hole'. This password is temporary, but it will be there,
>> clear text, for some time.
>>
>>>> Alternatively, I thought, for example, that a Squirrelmail plugin
>>>> could deal with 'register/change/delete' 'alternative e-mail', with
>>>> the 'forgot password' button and whith the form to get user
>>>> information when he/she forgots the password. For example, at each
>>>> 'user request to recover password', Squirrelmail just stores a file,
>>>> similar to lockout_plugin, with information got from user and 'local
>>>> procedures' take care of the rest of the process.
>>>
>>> You're right, more of this can be integrated into SM than I originally
>>> thought, but it's still complex and risky.
>>
>> Actually, with your considerations, I see that integration is more
>> complex than it appears at the beginning.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----
squirrelmail-plugins mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-plugins@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins