Password reset link vs Temporary password

Question

Which is harder to exploit: Password reset link with tokens/timestamps/code/ticket etc Or, temporary password sent on user mail using which login can be done and password can be changed.

Any suggestions on how they can be exploited please?

Answer 1

I an not sure how to directly exploit the Password reset links but the link pattern can be definitely used for Phishing campaigns. However for temporary passwords I feel that their strength depends on how guessable they are and how strong the password generating algorithm is. If they are random like OTP, there might be issue of randomness.

Answer 2

Receiving a plain text password (That the user must change upon login) and receive a link with a token it's the same, as long as they meet security policies that are not attached to any type by its own. Some good policies are:

1. Time based expiration of the temporary password or token.
2. Complex and random generated passwords/token (Not guessable, based on user's data)
3. Generating the new password sent by email should not invalidate the current user's password, since as pointed out by user multithr3at3d, it would cause a DoS to a legitimate user if the request would have been executed by an unauthorized person.

Answer 3

Which is harder? TLDR; Password recovery links.

There are a lot of nuances with account recovery processes. This is why they are problematic to implement effectively.

First, sending temporary passwords usually overwrites the user’s existing password, locking them out. As mentioned in here, it’s a form of Denial of Service. Also, systems don’t always force you to change the temporary password. This is convenient for users, to store their passwords in their mailbox. It has also inadvertently caused a bad habit to be passed on.

Password reset links are preferred as they do not lock the account out, are time limited, and have a random element that is not easily brute forced, and expire after being used.

As I mentioned, there are obviously nuances to consider, but can be distracting.

• Email isn’t always sent over TLS connections during routing, so it could be intercepted.
• An attacker could intercept connections between you and the server during the reset process.
• Users may not be forced to login again, and cookie could be insecurely configured.
• Password inputs could be posted to HTTP endpoints
• An attacker could monitor keystrokes on your workstation.

In most cases, MFA usually comes to the rescue, even when an attacker knows your password, it is even more difficult to gain access.

(MFA also has weaknesses, like prompt fatigue, SIM takeover, etc, but that’s for another day)

Exploit paths

Assuming you mean account takeover. Examples provided are illustrative and not comprehensive:

Temporary password:

• Phish target user, steal password
• Sign up, do password reset, identify routing, identify weak mail server, breach mail server, identify password.
• Initiate thousands of password resets, identify password entropy, predict next password.
• Phish user, interact with service via the phishing site, ask user for temporary password confirmation.

Password reset link:

• Initiate thousands/millions of resets, identify entropy, predict next reset URL
• Phish user, interact with target site, ask user to paste URL as confirmation of receipt, set password to known value.