[tmaher]

It was actually slightly more dumb than that.

Like most sites, after you register your account, we generate a nonce and email it to the provided address. You click the link with the nonce, we prompt you to set your password, and your account is ready. Our bug was that for already-verified users, the nonce column in the database is empty (it's a nonce, you see, so we only use it once...). This was the root cause for both bugs Mr. Sclafani describes.

[bgentry]

The ActiveRecord query that caused this was along the lines of:

    User.find_by_email_and_token(params[:email], params[:token])

If the token is nil, it basically turns into a `find_by_email`.

I'll also add that while we had tests that were intended to avoid this bad behavior, these tests were unfortunately broken and were instead verifying the incorrect behavior.

[wulczer]

It's interesting how differently Django handles password resets - no nonce is generated.

Instead, the user is emailed a token that's just her user ID, HMAC-signed with the last login date and a secret site key.

You can't generate valid reset links without knowing the secret key and you can't tamper with the one you got because it's HMAC-signed. By adding the last login date to the HMAC you make sure the link can be used only once. After a user resets her password, the last login date is updated to now so the link is no longer valid due to broken HMAC.

I like this solution because it doesn't rely on storing any state anywhere between requesting the reset and completing it.

[mikey_p]

This is pretty much exactly what Drupal does as well, with the exception of using the user's password hash instead of the ID as input before hashing and it also stores the timestamp of the reset request as part of the URL (and the token) to allow for expiring password resets.

[zapu]

Thank you for being open about that issue. All the reading about vulnerabilities definitely made me more aware when writing critical parts of my applications.