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

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

Re: Hide email validation in "Lost password" page? -- Security bug


From: Victor Engmark
Subject: Re: Hide email validation in "Lost password" page? -- Security bug
Date: Thu, 19 Apr 2007 09:18:20 +0200

On 4/18/07, Davi Leal <address@hidden> wrote:
Victor Engmark wrote:
> Davi Leal wrote:
> > Victor Engmark wrote:
> > > For users to be able to detect their error after the fact, we could
> > > let the email stay in the field after submission.
> >
> > Good point.
>
> Actually, it would probably be even better to redirect the user to the front
> / login page, since that's where they would logically be going afterwards.
> We could display a prominent message to confirm that we did something.
> Modified the task accordingly.

When the user goes to the Lost password page, what he/she wants to do is
be able to log in.

After we process his/her lost-password-request, and show the prominent
message "You should receive an email with ...", he/she is ready to use
the omnipresent :) login box, under the menu, to log in.

So I think there is not need to do a redirect.

I'd still argue that the "lost password" page is the least useful place the user can be after submitting a request. Since we don't have a separate login page, the front page is probably the most useful at that moment.

> > > To stop pranksters and accidental double-clicks from annoying users,
> > > we could also add a restriction that no email will be sent if an
> > > email was sent to the same address less than X seconds / minutes
> > > before. We should probably change the message to reflect that, to
> > > avoid even a white lie (ref. "your email will arrive shortly").
> >
> > This extra addition requires we create a new field at the E1_Entities
> > table to save the last lost-password-request time stamp. But with the
> > current data base model, we can only do it for the emails (entities) which
> > are already registered. So the spammers could note what email exists doing
> > several quick requests.
>
> No, because we won't tell them whether an email was actually sent or not.
> I'm thinking about having something like the following as the message for
> the user:
> You should receive an email with your (new?) password shortly. For security
> and privacy reasons, we'll only send to addresses registered at GNU Herds,
> and maximum once per X minutes.

OK, now I agree with you.  So we will have to add a new field at the
E1_Entities table to save the last lost-password time stamp, for example:

     E1_AbuseLastTime

We could use that field to, to combat abuse at the login box. Do you
agree? Do you have a better field name?

Why "E1_"? Anyway, I'd call it LastPasswordRetrieval or just PasswordRetrieval (less clear). Separates the information from the function(s), which could be several.

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