Prevent malicious verification flooding of e-mail addresses of others

[aleksejrs]

Currently it is easy to flood someone’s e-mail address with sign up verification e-mails.

Although the victim can easily delete the e-mails, they will probably mark them as spam, or set a filter up, so that when they try to register a BrowserID account themselves, they won’t get the verification e-mail.

One way could be creating a mandatory delay between sending verification e-mails, e.g. a 15-second delay after the first one (in case the e-mail message is lost), more after the second one, and even more for each subsequent one.

That is unless:

• an actual verification happens;
• the address is known to have been used with this identity provider (recently/often? Note also the possible abuse of + suffixes).

In case the address owner trusts the provider with his address, but doesn't need an ID account, there might also be a way for him to choose a delay himself (but not too long a delay, and real spam often contains "unsubscribe" links and is intended to verify e-mail addresses).

[lloyd]

we should agree on some simple heuristics and implement them post-haste, as this might entail new database requirements, we should figure it out sooner.

[lloyd]

proposal (by @stomlinson) - not more frequently than 5 minutes.

Lloyd will adjust the api, then pass to stomlinson to add a nice user facing error page.

Good starting point?

[benadida]

yes, great. Another simple (and long-term) starting point is exponential backoff of sorts. 15s the first time, 30s the next... Though that may require tracking one more field. I don't feel very strongly about this, previous solution is fine by me.

[lloyd]

I like exponential backoffs. I like that this only requires 1 extra field (and not another table).

[lloyd]

tag, @shane-tomlinson, you're it! I went with a trivial implementation, a minimum time that may elapse between emails to a given email address, and that's set at 60s for now. We can tweak this as we see fit.

@shane-tomlinson - you'll get an http 403 response to stage requests when you try to take two actions that would send an email to the same address within 60s of each other. So if you get a 403 here you can tell the user something like "We just sent an email to that email address! If you really want to send another, wait a minute or two and try again."

[lloyd]

@shane-tomlinson beautiful! nice doing business with you.

[ghost]

Verified on Windows 7 with Firefox 7.0.1 and Chrome 14. If the user clicks "Verify Email" less than 1 minute after he already did it once, a tooltip is displayed. After 1 minute, the user can ask for another email to be sent and the email is sent.