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