gnuherds-app-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Victor Engmark
Subject: Re: Security bug at Lost_Password.php and Person.php, Company.php & non-profit_Organization.php registration forms
Date: Fri, 20 Apr 2007 10:06:23 +0200

On 4/20/07, Davi Leal <address@hidden> 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.

> 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?

> > 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.

> 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.

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:
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.

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.

--
Victor Engmark
Quidquid latine dictum sit, altum videtur - What is said in Latin, sounds profound
reply via email to

[Prev in Thread] Current Thread [Next in Thread]