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: Davi Leal
Subject: Re: Security bug at Lost_Password.php and Person.php, Company.php & non-profit_Organization.php registration forms
Date: Fri, 20 Apr 2007 01:16:29 +0200
User-agent: KMail/1.9.5

Sorry for this incomplete analysis. Read below:



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.

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


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

As usual, I will upload to production the source code when ready, but I will 
not commit it up to you agree.

Davi




reply via email to

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