Re: Security bug at Lost_Password.php and Person.php, Company.php & non-profit_Organization.php registration forms

[Davi Leal]

Victor Engmark wrote:
> Davi Leal wrote:
> > Victor Engmark wrote:
> > > Davi Leal wrote:
> > > > It is not just for password retrieval, we have to use too for the
> > > > register forms, due to they has the same security problem.
> > >
> > > True! By the way, I think it should be possible to register both a
> > > person and a company under the same email address - It's sure to be
> > > interesting for some individuals, e.g., startups.
> >
> > Such individuals can easily have two different emails, one for personal
> > use and one for the start-up. Emails are cheap today.
>
> Yes, but it's another usability feature lost.

It is too much complexity to almost no gain. Emails are cheap today. We
must keep the project easy to learn and to maintain.


> > > I propose to split E1_Entities into
> > > one table per entity type, and create an entity view if necessary.
> >
> > We tried that some time ago, and problems arose about managing the E1_Id
> > key.
>
> Sounds like a DB redesign could be in order. What do you think?

Absolutely no. The design is very clean and easy to expand, as yo will see
now if finally you develop this bug fix.


> > > > What I propose is to add the above new field to the  E1_Entities
> > > > data base table, and use it to save any of the below time stamps:
> > > >
> > > > 1. The last timestamp related to   Lost_Password.php, and
> > > >
> > > > 2. The last timestamp related to   Person.php, Company.php or
> > > >     non-profit_Organization.php register forms.
> > > >
> > > >     I propose too this second case (2.) due to the Person.php,
> > > >     Company.php & non-profit_Organization.php register forms has too
> > > >     the same security problem, due to when a new user try to register
> > > >     to the web site, if the email she want to use is already at the
> > > >     data base, those forms shows a warning:
> > > >
> > > >       "You can not use it, ... that email is already used
> > > >        in the data base ..."
> > > >
> > > >
> > > > What do you think?
> > >
> > > Good idea! Actually, it looks like we'll have to have two steps in the
> > > registration process, separated by an email to the address provided with
> > > either a validation link or an error message. Still protects the user's
> > > privacy, but with a bit more hassle.
> >
> > I agree.  I think the "validation link" is the way to go, similar to the
> > one used right now at the Lost password form.
>
> I don't understand what you mean by the last part, so I'll just clarify: I'm
> thinking about sending an email to the user, with a link like
> http://gnuherds.org/register.php?validation_id=934dpc.pdu90,34pk'34p98fj'23k8pf38pfko8fo.7yf.yo.d87y9d,
> where the validation ID is stored in our database, and clicking on that link
> will continue the process of doing whatever the user requested that had to
> be validated.

The below link is the validation link which are being used right now at
the Lost password form:
https://www.gnuherds.org/address@hidden&magic=ccf8909545697460694f50f9c12d76ef

I advise you try several times the Lost password form with your account.
So, you will take a look at the current functionality.


> > > I guess we should have a FAQ item for
> > > people receiving multiple registration emails or error messages. In the
> > > case of an error message, the user probably should just be pointed to
> > > the password retrieval page.

There is not need of a FAQ. The own email explain it to the user:

 "For security reasons, GNU Herds does not send passwords by
  electronic mail.
  To get your new password follow the below link:
    https://...
  If you have not asked for a new password, ignore it and your
  password will not be changed."


> > We can use all the below ideas to fix this security bug:
> >
> > * The protocol you have proposed at
> >
> > http://lists.gnu.org/archive/html/gnuherds-app-dev/2007-04/msg00155.html
> >
> > * The new E1_Entities field
> >      E1_LastTimeStamp
> >
> > * At the registration and email modification processes we will send a
> >    "validation link" to the email before accepting the user request.
> >
> > If it is needed, we must follow talking about it.
> >
> > If you agree, I will carry out this task:
> >   Task: https://savannah.nongnu.org/task/index.php?6786
>
> I think I do, but I just have to make sure we're talking about the same
> thing. The bug report didn't really have much information, so I'll just
> summarize. There are several bugs in question:

If you are going to develop the bug fix, please do not commit it. First
send it to the list.


>    - Any person can use the registration or password retrieval forms to
>    find out whether a particular email is registered at GNU Herds. This is a
>    privacy and spam (email validation) issue.

Right.


>    - A person can use the password retrieval form at any time. This is a
>    spam issue, and can be fixed by imposing a delay between each time
>    submitting the form will actually send an email.

Right.

Additionally, note that after you add the validation link feature to
the  registration forms, they will have too this problem, so we will have
to use E1_LastTimeStamp too to avoid it.


>    - If we implement such a back-off algorithm, we should inform the
>    user, when submitting the form, that an email will not be sent
>    if there's been less than X minutes since the last submission.

OK.


>    - It is possible to submit a wrong email address at Person.php. This
>    is a privacy issue (since the erroneous email may belong to someone else),
>    and a safety issue, since the user will be unable to receive a password
>    retrieval email.

We can not avoid the privacy issue, due to it is the fault of the user who
fill erroneously the email field.

I think there is not "safety issue". The user just not receive the email.


>    - If we implement the proposed system (or something similar),
>    it will be possible to receive multiple validation
>    emails to the same address. We should in that case create a FAQ entry for
>    those who receive an email and don't know why or what to do with it.

As exposed above the email already explain itself. We must write some
similar email for the registration forms case.

>    This
>    entry should probably be referred to in both the email and the validation
>    page (which would show an error because an attempt was made to register the
>    same email twice).

The validation link, of course, goes only in the email sent.

The fact that this email was used in an attempt to register twice will
be reported only in the email sent, to avoid the bug we are talking about.
No at the web page.


>    - Also, if we implement the proposed system, we should show a link to
>    the password retrieval page after a validation fails. I believe a common
>    reason for attempting to re-register an email is that the password or
>    account has been forgotten.

Good point!, but when we detect an attempt to re-register, we must note
it, and add the link to the lost-password page, only at the email sent,
not at the web page,  to avoid the bug we are talking about.


> I just realized an improvement to the back-off algorithm (I'm sorry if it's
> already implicit in your emails): Use the timestamp of the last form
> submission, not the last time an email was sent. That way, hammering our
> server won't result in any emails to the user, instead of one every X
> minutes.

Of course.


> A really advanced algorithm would keep track of hammering, and e.g. double
> the time until the next submission will work for each time the server is
> hammered (up to a reasonable threshold, of course, e.g. a day).
> Unfortunately, such an implementation could conceivably be used to break
> privacy, if the malicious user is able to detect that the proper user has
> requested a new password lately. Therefore, I don't recommend it.

I agree with you about this point.


So, you can develop this bug fix, and send to the list your result, so as
to all we can fix or improve it. Along you develop it, we must follow
improving the proposed solution.


P.S.: I hope get some time tonight or tomorrow to finish the <div>
convertions.

Davi