Re-authenticate with WebAuthn instead of password

[di]

Right now, when a user is prompted to re-authenticate for sensitive actions, they are asked to provide their password.

For users with 2FA enabled, this should instead require authentication with the 2FA device.

[di]

@miketheman Any interest in this one?

[miketheman]

@di sure,sounds interesting. To be clear, these would be fore views that set require_reauth=True, like this one?
https://github.com/pypa/warehouse/blob/25ffc1f0f0a0dadbb140e8ac0428917fd621ac1f/warehouse/manage/views.py#L426-L437

At first glance, couldn't we get into an impossible condition for this specific view?

[di]

@miketheman Correct, for require_reauth views.

Regarding an 'impossible condition', do you mean that the request to remove a 2FA method might require that 2FA method?

[miketheman]

Thinking about it more, the point of recovery codes is to handle if/when you lose your 2FA device, so there's that eventuality handled.

I'll take a pass at writing up some test cases to express the desired behavior and see how it goes.

[miketheman]

Was reading more today, and Auth0 terms this Step Up Authentication - so I may use some of this terminology as well - so we can make a distinction of "reauthentication == user/pass again" vs "step up == use the second factor".

[miketheman]

I've been digging through this problem, and the main entry point is inside the reauth_view view deriver (I learned something new! ✨)

It looks like there's a couple of directions we could take here:

1. Extend existing forms to accept params that the reauth form does like next_route, add conditional logic to the html template, and pass a form class to the view route to change the behavior on the fly
   • This could be more DRY, but at the cost of complexity with existing code and behaviors
2. Add 2 more forms for totp and webauthn, 2 more html templates, 2 more view routes to handle the form submission/validation
   • This is a non-DRY approach, but likely the simplest, and once implemented we could examine the approach for a refactor.

I'm leaning towards the second option, since it's probably "good enough" to start the conversation, but if there's some specific Pyramid/zope tricks around route parameter injection, or other magic in mind, I'm all 👂👂.