The rate-limiting mechanism on 'invalid' email-registration requests locks out users for one hour

[Chris]

Steps to reproduce:
1. Login to Psiphon
2. Go to the 'profile' page
3. Submit an email address that has already been registered (on a different account) with Psiphon
4. Go the inbox of the chosen email address, wait for the validation email, and click the link
5. Psiphon will present an error message
6. Logout from Psiphon, if necessary, then login again as the same user
7. Attempt to register a different email address
8. Psiphon will present an error message

Should rate-limiting only trigger on _successful,_ validated email addresses?

[Adam P (adam+)]

One of the goals of email verification was to prevent a malicious user from using Psiphon to spam other people (partly so that we're not a nuisance to people, partly so that we don't end up looking like a spammer). If we allow no-rate-limited unsuccessful change attempts, then a malicious user can just keep putting in email address and forcing us to send out rapid-fire emails to whomever he wants.

This is related to another problem that has been discussed that I'll be adding a bug for shortly. (And then I'll add a link to it from here.)

I'm going to mark this as invalid. But if you have further input or I've missed the point, please add comments.

[Adam P (adam+)]

Related to (and possibly would be fixed by) bug #552603

[Chris (poser)]

I still don't think we're rate-limiting in the right way. What about
three attempts per hour? That should be enough for a user to come up
with a valid email address, and is no more of a spam threat....

Or, better yet, what if clicking on a received validation link reset the
timer, even if the registration attempt failed (in this case, because it
corresponded to an existing email address)? In the spamming scenario,
the user is still rate-locked, but in the honest-mistake scenario, the
user is able to send herself another email-registration
validation-request (presumably at a new email address).

(Of course if psiphon threw an error when users attempt to register
pre-existing email addressses, this would not be an issue. Presumably,
we avoid this because it would allow an adversary to enumerate email
addresses?)

> One of the goals of email verification was to prevent a malicious user
> from using Psiphon to spam other people (partly so that we're not a
> nuisance to people, partly so that we don't end up looking like a
> spammer). If we allow no-rate-limited unsuccessful change attempts, then
> a malicious user can just keep putting in email address and forcing us
> to send out rapid-fire emails to whomever he wants.
>
> This is related to another problem that has been discussed that I'll be
> adding a bug for shortly. (And then I'll add a link to it from here.)
>
> I'm going to mark this as invalid. But if you have further input or I've
> missed the point, please add comments.
>
> ** Changed in: psiphon
> Status: New => Invalid
>

--
<email address hidden> (PGP key at http://www.aduni.org/~walker/key.html)

[Chris (poser)]

I still don't think we're rate-limiting in the right way. What about
three attempts per hour? That should be enough for a user to come up
with a valid email address, and is no more of a spam threat....

Or, better yet, what if clicking on a received validation link reset the
timer, even if the registration attempt failed (in this case, because it
corresponded to an existing email address)? In the spamming scenario,
the user is still rate-locked, but in the honest-mistake scenario, the
user is able to send herself another email-registration
validation-request (presumably at a new email address).

(Of course if psiphon threw an error when users attempt to register
pre-existing email addressses, this would not be an issue. Presumably,
we avoid this because it would allow an adversary to enumerate email
addresses?)

[Adam P (adam+)]

I agree that we could do the rate-limiting in a more forgiving manner that would still prevent the spam problem.

However #1: I can't really think of a use case where it makes sense to let a user try again when he/she is trying to create an (/another) account with an email that's already in the system. The already-existing account should either be deleted (and so de-conflicted) or recovered.

However #2: It would likely be easier to change the rate-limiting scheme than to implement any of the account-deletion/recovery changes suggested in bug #552603. So I'll mark this as not-invalid.

[Adam P (adam+)]

Fixed by user-proxy association enforcement relaxation. The rate limiting hasn't change, but the scenario that let to the bug reporter's problem cannot occur now.