search

hasgeek / funnel

Website for hasgeek.com
https://hasgeek.com/
GNU Affero General Public License v3.0
46 stars 52 forks source link

Sudo prompt should allow OTP authentication even if an account has a password #1894

Open anishTP opened 1 year ago

anishTP commented 1 year ago

Context

The user tries to update critical details on their project and are prompted to provide a password to authorize the action.

Problem

The current sudo check flow prioritises OTP sudo check over password sudo check. For users who login using an OTP and have no password this pattern does not allow authorizing critical edits or delete actions in project/accounts. Additionally in scenarios where the user has forgotten their password, the reset prompt does not allow for a reset through OTP.

jace commented 1 year ago

This is for the sudo check, not for login. If the account has a password, it shows a login prompt without an option for fallback to OTP.

This differs from the login flow where OTP is the default flow but password login is available as a fallback option.

One complication for sudo: it does not have a hint for where to send the OTP if the user has multiple contacts (email or phone), whereas during login flow the user provides it.

Should sudo offer a choice of where to get the OTP? Is that a risk as it reveals information about the account (even if contacts are masked)? Should we assume this risk is okay as the user is already logged in?

anishTP commented 1 year ago

Yes correct.

Suggestion: The sudo check could default to a OTP via SMS in case the phone number field is not NULL else via email. This way the user doesn't have to make any choice or risk revealing their contact information.

jace commented 1 year ago

We have to account for the failure conditions:

  1. SMS delivery is unavailable for the phone number (transport outage, service discontinued)
  2. The account has multiple phone numbers and the wrong number is marked as the default, so the user can't identify where it went
  3. Same, but that number is obsolete, so they can't receive at it
  4. Email OTP went to an obsolete corporate email address

The OTP flow should ask the user where they'd like to receive it. Anyone logged into the account can see all contacts in /account with further authentication, so I don't think there's an additional security concern with offering this choice here.