Comment 4 for bug 589335

Agreed with using the same table.

We currently select from 50 characters to generate tokens. A 4-character token would give ~6M possibilities. Even with a slightly longer token, we might want some additional security.

Łukasz and I discussed adjustments to the workflows to maintain good security with the shorter tokens. For new accounts and password resets, we settled on requiring the e-mail address that the token was sent to along with the token itself. This would significantly increase the amount of work required to guess or brute-force a token and capture an account. API-based clients could cache the e-mail submitted when requesting a new account or password reset, and re-submit it once the user has the token in hand.

For new e-mail addresses on existing accounts, we agree that the user must log in (or already be logged in) as the account owner to use the token. We are undecided whether the target e-mail address must also be entered.