Document social/UX implementation stuff/provide tips for a secure way of using this lib

[rugk]

Some questions users/implementers of this lib may have:

• How do I/should I handle password resets?
• Should I allow support stuff to reset 2FA codes? Why (not)?
• Should I force users into generating recovery codes? Why and how?
• When to require such a (re)authentication? If so how? (see how GitHub e.g. allows it with a password or MFA mode)
• How to communicate that thing to users, so our support team does not get overhelmed with thousands of users being locked out?
• etc. etc.

So in a full (real) implementation, thus users of the lib (aka "implementors") of course have to consider all these quite tricky UX/security-related things. It is strictly speaking not your responsibility to help here, but IMHO it would be very nice if you could at least provide some pointers. Even because you start it in a good way by explaining security considerations. Looking over the edge of your lib would IMHO be great.

A good link I found would be the brief but good OWASP cheat sheet on the topic, especially the resetting thing.

[xi]

Thanks for the feedback! I really appreciate that.

As you already wrote, this kind of advice is a bit out of scope because it applies to multi factor authentication in general, not just this library. Still I agree that it would be helpful to point people in the right direction. Do you think it would be sufficient to include the OWASP link in the README? Can you maybe create a pull request with a proposal?

How do I/should I handle password resets?

Can you elaborate on that?

In the project for which I originally created this library we do not have password resets, so I admit I haven't thought about it too much.

My expectation would be that you can reset your password, but when you try to login with the new password you would still need to provide the second factor. So the two are completely independent. Or am I missing something?

[rugk]

How do I/should I handle password resets?

Can you elaborate on that?

Well… if the user can reset the password with their mail only, and not provide a new 2FA/other factor for authentication, your whole 2FA system is of course broken, because mail is hardly more trustworthy than any single factor you use for login (password, WebAuthn key etc.).

My expectation would be that you can reset your password, but when you try to login with the new password you would still need to provide the second factor. So the two are completely independent.

That may be a possible solution yes.

Do you think it would be sufficient to include the OWASP link in the README? Can you maybe create a pull request with a proposal?

Both yes, and I'll do.