Unhappy paths in SMS-Codes setup flow

[winstonwolff]

@jeremyevans —

Thanks again for help on our previous issue of encrypting Account.email. It's working great. I have a new question if you have the time:

Attached is a flow I have in mind for users setting up SMS codes. The happy path, making your account and adding SMS codes works. But I'm having trouble getting two unhappy paths working:

(a) If on the /setup-sms page, one accidentally enters a wrong phone number, one cannot use the browser to go back to re-enter it. The browser's back button keeps redirecting to /sms-confirm. I thought I might be able to use the /sms-disable route, but that didn't seem to work either. Any ideas?

(b) If I entered the correct phone number, but the SMS does not go through (it happens occassionaly that an SMS message is lost), how could I re-send the confirmation code?

Thanks, Winston

[jeremyevans]

Thanks for bringing this up. I think you are correct, there probably isn't a good way to handle either unhappy path currently. While I recommend against SMS authentication (it is by far the worst second factor), I agree that both unhappy paths should be handled better. I'll try to work on this before the next release.

I think one of the easiest ways would be if the sms-confirm action fails, remove the sms phone number, and redirect to sms-setup so the user can try again. That should handle both the wrong phone number and code not sent issue. I'd like to use an approach that solves the basic need with the minimum of complexity, even if the user experience is suboptimal. This approach would avoid having to support separate action handling for the back/resend cases.

[winstonwolff]

I agree with your basic ideas, removing the 'sms_codes' entry if the user fails 'sms-confirm', which would let them retry. I also agree with solving with the minimum complexity. One mechanism to remove the associated 'sms-codes' row should work well. Although we should check that one can remove the sms-code only the first time one is confirming, to avoid an attacker arbitrarily disabling SMS.

[jeremyevans]

I had the time to look into this in more detail, and it turns out this is already the way it works. Any invalid sms code during confirmation removes the sms entry, and redirects to the sms setup page. Trying to access the sms confirmation route when sms is already setup is not allowed. So I don't think changes actually need to be made. Sorry I didn't remember this, I haven't had to change how SMS confirmation works since I wrote the code back in 2016.

If you want to be a bit more user friendly, you could do:

  sms_confirm_additional_form_tags "<input type='button' value='Back/Resend SMS' />"

That adds a button to make it a little more clear to the user what to do if they want to go back or resend SMS, even though it has the same effect as clicking the "Confirm SMS Backup Number" button.

[winstonwolff]

We tried this, and it kinda works, but it presents a flash message something like "confirmation code is invalid, start over." I'm just mentioning it to you FYI, but we have solved our problem with your first suggestion—to have our own action that deletes the account's sms_code:

  # If you are part way through SMS setup but need to cancel, go to this page.
  def cancel_sms_setup
    user_has_no_sms_setup = rodauth.rails_account.sms_code.nil?
    if user_has_no_sms_setup
      redirect_to rodauth.sms_setup_path
      return
    end

    user_has_verified_sms_before = !rodauth.rails_account.sms_code&.num_failures.nil?
    if user_has_verified_sms_before
      redirect_to rodauth.sms_auth_path # don't allow SMS to be canceled if it's been setup fully.
      return
    end

    rodauth.rails_account.sms_code.destroy
    rodauth.rails_account.reload

    redirect_to rodauth.sms_setup_path
  end

[winstonwolff]

Why do you say SMS codes are the worst second factor? Is it because Sim cards can be copied, or because people forward their text messages to their computers?

[jeremyevans]

It's not SIM card copying, it's that it's not very difficult to redirect phone numbers to other devices (often just takes a social engineering attack on the staff of any cellular phone company, at least in the US). Using SMS as a second factor gives a false sense of security, IMO. Both TOTP and webauthn are much more secure.