I am currently implementing a change-of-email request flow for a web service without MFA. My initial approach is to consult the current OWASP Guide for such a flow. In reading the document, I've realized this is quite different from the flow I typically see on websites, even Fortune 100s.

The TLDR for the OWASP recommendation is:

  1. Verify user session upon request
  2. Send two emails with confirmation and cancellation URL, both time-limited and linked to the user.
    1. One to the user's current address
    2. Another, to the user's new address
  3. Only after requests have been made to BOTH confirmation URLs, the account information in the data store is changed.
  4. If a request is made to either the cancellation URLs, the flow is cancelled.
  5. After that, typical session invalidation / force re-authentication.

This all sounds good and quite secure, but it doesn't align with what I see implemented in the wild. A more typical flow, for example on Reddit is:

  1. Re-authenticate user with password upon request
  2. Send a confirmation link to the new email address
  3. (optionally seen on many other sites) Include some message that "If you did not make this request, this email can be safely ignored"
  4. Upon confirmation, change the address of the user in the data store

My question: Is this abridged flow sufficient from a security standpoint?

  • 1
    "Is this abridged flow sufficient from a security standpoint?" - there is no generic "sufficient", it depends on the use case. Security is always a trade-off: more security usually impacts usability or even functionality - for example the cited recommendation fails if the user has no longer access to their old mail which isn't that uncommon. What is acceptable depends on what you need to protect and on the threats. Therefore there is also no generic "correct" way - even though there are several obviously wrong ways. Jan 22 at 20:02


You must log in to answer this question.