5

I like the look of this technique for sending password reset links:

https://neosmart.net/blog/2015/using-hmac-signatures-to-avoid-database-writes/

(TLDR: don't store token in database. Send password reset link w email address, expiry time, and corresponding hmac)

especially after reading about the Mozilla / Bugzilla reset bug.

It seems like it's vulnerable to replay attacks though.

Q1: Under what circumstances is it vulnerable, assuming good HTTPS?

I think someone monitoring my network traffic (at say a wifi hotspot) would not be able to simply replay the GET request to the link, correct?

Q2: If it's only a replay attack if an attacker has access to my email or physical access to my computer, isn't token-based password reset equally vulnerable, as the attacker could simply request a new link?

1
  • 1
    The post suggests that the oldBcryptHash should be part of the secure token. Assuming that you actually did change your password to something else when you clicked the link, the hash would no longer match for future attempts and validation would fail, so wouldn't this eliminate any replay attacks? Commented Sep 27, 2015 at 1:03

1 Answer 1

2

The major risk of email password reset systems is the SMTP transport of the reset token.

Any competent email infrastructure will use either HTTPS (HTTP/TLS) webmail, IMAPS (IMAP/TLS), or POP3/TLS, or a proprietary protocol like MAPI/TLS. If not, get another provider ASAP.

Your visit of the reset token link itself use HTTP GET over TLS and the only thing the attacker can see is TCP connection level info (source/dest port/address).

This leaves the attacker with only SMTP interception on the Internet, at the sender network, or at your mail provider's network. That's not economical for most attackers unless you are a high-value target like a CFO or other individual with valuable privileged data access.

If the attacker has access to your email via account compromise they can get new reset links. A two factor token would mitigate that. If the attacker has compromised your endpoint they can steal your session directly. A defense for that is for the application to lock sessions to particular hosts.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .