Re: [SM-PLUGINS] Idea for a new plugin/feature: a 'forgot my password' option

[<ca...@gm...>]

Sorry for taking so long to answer.

On Mon, Aug 3, 2009 at 5:57 PM, Paul Lesniewski<pa...@sq...> wrote:
> On 8/2/09, ca...@gm... <ca...@gm...> wrote:
>> On Sun, Aug 2, 2009 at 3:06 PM, Paul Lesniewski<pa...@sq...>
>> wrote:
>>> On 8/2/09, ca...@gm... <ca...@gm...> 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 'joe...@al...d'. Is
'joe' forgot his password,  he clicks on 'forgot my password', inputs
'joe...@al...d', 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