1351648 - [fxa][Staging 83] Confirmation email not expired after an hour

Status: RESOLVED WONTFIX

(Cloud Services :: Server: Firefox Accounts, defect)

Description

[Sorina Florean [:sflorean]]

Device: HTC Desire 820 (Android 6.0.1), Huawei MediaPad M2 (Android 5.1.1)
Environment: Staging server [Train 83]

Steps to reproduce:

1. Go to any Create account form;
2. Follow the steps for creating and tap on "Save settings";
3. Wait an hour and after that go to mail and tap on verification link.

Actual result: 
After step 2, an email to confirm the account is send.
After step 3 the confirmation email expires.

Expected results:
After step 3 the link from mail confirms the sign-in. The link wasn't expired.

Notes: is the user taps on "Back. Didn't arrive and not in spam folder? Resend" and in mail are two verification links, both are working.

Comment 1

[Sorina Florean [:sflorean]]

This issue is reproducible on Staging server [Train 84]

Comment 2

[Sorina Florean [:sflorean]]

Reproducible on Staging server [Train 87].

Comment 3

[Ryan Kelly [:rfkelly]]

I believe this is intended behaviour.  When you crease an account, we send you a verification email with a link, and the link never expires.  We should consider whether we're happy with that behaviour though, so ni? two folks to weigh in here:

* :ulfr, how uneasy are you with the current behaviour where "verify your account" links sent via email do not expire?
* :adavis, how wedded are you to the current never-expiring behaviour from a product perspective?

Comment 4

[Greg G]

(In reply to Ryan Kelly [:rfkelly] from comment #3)
> I believe this is intended behaviour.  When you crease an account, we send
> you a verification email with a link, and the link never expires.  We should
> consider whether we're happy with that behaviour though, so ni? two folks to
> weigh in here:
> 
> * :ulfr, how uneasy are you with the current behaviour where "verify your
> account" links sent via email do not expire?

:ulfr asked me to comment on this.

OWASP recommends an 8 hour expiration, but doesn't say how they picked that duration: https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#Email_Validation_Basics

If it's just a capability url, we don't see a problem having it live longer beyond making it slightly easier to guess a code and eating up some db space. It's not a concern to fix right away but should expire in a week to a month.

If it logs in automatically, then it's a password equivalent and we shouldn't do that or it should expire very quickly.

Comment 5

[Ryan Kelly [:rfkelly]]

> If it logs in automatically, then it's a password equivalent and we shouldn't do that or it should expire very quickly.

ack; just confirming that they do *not* do this :-)

Comment 6

[Ryan Kelly [:rfkelly]]

After digging into this some more, it turns out that the assumption that these links to do expire is baked in pretty deep to our code.  We can change it, but it will not be trivial, and I'm not convinced the incremental security would be worth the investment.  I'm going to tentatively WONTFIX this, but am open to the suggestion that we should re-evaluate as we work our way through adding support for multiple emails.

Comment 7

[Alex Davis [:adavis]]

I'm a bit confused.

:Sorina said that the link EXPIRES in her test.
>Actual result: 
>After step 2, an email to confirm the account is send.
>After step 3 the confirmation email expires.


:rfkelly responded that it's not suppose to expire:
>I believe this is intended behaviour.  When you crease an account, we send you a verification email with a link, and the link never expires.

We closed the bug saying that it is hard to change and is doing the intended behavior. But IIUC, it is not doing the intended behavior.

Comment 8

[Ryan Kelly [:rfkelly]]

Hmm, you're right, I think I formed an opinion here based on the bug title "Confirmation email not expired after an hour" and the comment "two verification links, both are working", and interpreted the report as "the links are not expiring when I expected them to".  But that doesn't match the reported STR.

Sorina, can you please clarify, is the bug here that the confirmation links are expiring when they shouldn't, or that the confirmation links are not expiring when they should?

Comment 9

[Sorina Florean [:sflorean]]

(In reply to Ryan Kelly [:rfkelly] from comment #8)
> Hmm, you're right, I think I formed an opinion here based on the bug title
> "Confirmation email not expired after an hour" and the comment "two
> verification links, both are working", and interpreted the report as "the
> links are not expiring when I expected them to".  But that doesn't match the
> reported STR.
> 
> Sorina, can you please clarify, is the bug here that the confirmation links
> are expiring when they shouldn't, or that the confirmation links are not
> expiring when they should?

The confirmation links are not expiring when they should. If I resend the email with account confirmation, both emails are valid. Maybe the first email should have been expired, if there is another one for the same situation.

Comment 10

[Ryan Kelly [:rfkelly]]

> > We closed the bug saying that it is hard to change and is doing the intended behavior. 
> The confirmation links are not expiring when they should.

Thanks.  So to reiterate, the system was designed with this as the intended behaviour and it's not obvious how much work would be involved in changing this.  For example:

> If I resend the email with account confirmation, both emails are valid.

I would expect both emails to contain the exact some link, due to the way things are handled in the database.

We can change it, but it's not a trivial fix, so I'll lean on either a concrete security or product ask if you want us to prioritize this.