Multi Factor Authentication

[LukeTowers]

Initial notes from planning issue 4 years ago:

• Some drivers kick in after password / SSO auth, some kick in before (webauthn, hardware token)
• Challenge / Response workflow

Authentication Stack

• Multifactor
• Token-based
• Silent authentication through the cell network? Used more in the application world, sort of like SSO for phones through 5g and through carriers

Authentication Methods

• Password
• WebAuthN
• Magic Link (SMS / Email)

Multifactor Authentication Challenges

• SMS
• Phone call
• Email
• Over the top service (WhatsApp, telegram, signal) - side channel communications)
• Token (TOTP)
• Interactive
  • App based ones (Gmail, GitHub, Steam)
  • Yes No
  • Type in number on external service from login request

Other notes:

• Core phone number field

Drivers:

• SMS
• Email
  • Magic link
  • PIN

Dump of my notes on the subject here until we're closer to implementing in public:

Available factors:

• SMS
• Phone call / voice
• App push notifications
• TOTP
  • Token (usually scannable QR code) used to generate time-sensitive 6 digit codes
  • List of “recovery codes” generated and provided to user on token generation
• “Email” (not really, basically just requiring password reset to login every time)
• WebAuthN (like this the most because it integrates with device’s native methods, Windows Hello, FaceID, TouchID, smart keys, Yubikey, etc)
  • This supports multiple devices / integrations (phone, laptop, etc) with a list of authorized keys and a way to remove them if required
  • Could also be used for password-less authentication, but this is not 2FA and viable recovery methods for this basically boil down to logging in via email with all of the considerations that come with having that as the weakest link
• Null
  • Testing the flow without validating it. Not sure if useful since email is low friction enough to be used for testing the flow

Considerations:

• Want to have the same system powering both frontend and backend implementations
• Should we have the concept of drives powered by drivers? i.e. providers powered by drivers for multiple configurations of the same driver?
• Standard interface and events for registering additional drivers
• This way should allow for people to host their own “Authy” / “Verify” implementation without the extra markup of those tools
• User secrets should be encrypted
• Users should have a method on the model that retrieves the 2FA method in use for their account (application’s responsibility to surface the available options to the user) with a valid return being null / no enabled 2FA
• Contracts / interfaces should include a way to provide and utilize recovery codes
• How should password resets be handled on an account with 2FA enabled?
• Comment on Webauthn support laravel/fortify#22 when the feature is completed

WebAuthN flow:

Implementations in the wild:

• Banks
  • Forced SMS, phone, or email based on contact information on file
• Twitter
  • 2FA options
    • SMS
    • TOTP
    • Security key (WebAuthN?)
  • Sessions
    • Shows currently active sessions
    • Shows all other authenticated sessions and provides a way to log out of all of them
      • User agent device identification
      • Last access timestamp
      • Rough IP-based geolocation (could also be more precise through the location APIs although that’s client controlled and could be prone to manipulation)
      • Can log out of all the other sessions or log out of each individual session
    • Logs of last logins with user agent, IP address, and access date
    • List of connected apps
• Facebook
  • 2FA options
    • SMS
    • TOTP
    • Security key
    • Recovery codes
  • “Authorized logins”
    • Devices that do not have to use 2FA codes (by virtue of the device itself containing the 2FA code I’d imagine) (User friendly user agent and date of authorization)
  • Sessions
    • Same deal as Twitter pretty much
  • “App passwords”
    • Separate passwords to use to authenticate against the account without invalidating all existing sessions and authenticated devices when you want to remove the password.
    • Used more so for legacy applications that don’t have proper access through the API and instead use a username and password to connect in a flow that doesn’t support 2FA
    • Includes a user provided name for the password, the password itself in probably hashed form, and the date it was generated with the ability to remove one or all options
• GitHub
  • 2FA options
    • TOTP
    • Security keys (WebAuthN?)
    • SMS
  • Recovery options (note that these are just as valid as regular options, and security is only as strong as the weakest link)
    • Recovery codes
    • Fallback SMS number
    • Recovery tokens
      • External authentication integrations with other providers (i.e. only Facebook is an option at the moment)
      • Do not grant self-service access to the account, are only used to help verify identity when working with support teams to gain access to the account
  • Sessions
    • Same deal as twitter
    • Includes date of first access

Implementations:

• Laravel Jetstream
  • Only TOTP
  • https://jetstream.laravel.com/2.x/features/two-factor-authentication.html
• Laravel Fortify
  • Only TOTP
  • https://laravel.com/docs/8.x/fortify#two-factor-authentication
• Twilio Verify
  • https://www.twilio.com/docs/verify/api
• Twilio Authy
  • https://www.twilio.com/authy
  • Discontinuing in favour of Verify
• Simple email 2FA
  • https://blog.quickadminpanel.com/add-two-factor-email-verification-to-laravel-auth/
• TOTP apps
  • Authy for iOS, Android, Chrome, OS X
  • FreeOTP for iOS, Android and Pebble
  • Google Authenticator for iOS
  • Google Authenticator for Android
  • Google Authenticator (port) on Windows Store
  • Microsoft Authenticator for Windows Phone
  • LastPass Authenticator for iOS, Android, OS X, Windows
  • 1Password for iOS, Android, OS X, Windows
• TOTP in laravel
  • https://scotch.io/tutorials/how-to-add-googles-two-factor-authentication-to-laravel
• https://github.com/srmklive/laravel-twofactor-authentication
  • Uses “providers” for the various methods
  • Hooks provider is enabled for user check after successful login, logs out and redirects to token screen storing the password-authenticated user ID in the session
  • /auth/token page to receive the 2FA token from the user, redirects to login page if user ID isn’t present in the session
  • /auth/token post to receive the token, check for user id in session, and validate against provider
• https://github.com/webdev93/laravel-webauthn
  • https://github.com/asbiin/laravel-webauthn-example
  • https://github.com/asbiin/laravel-webauthn is the actual one I think
  • Routes
    • /webauthn/auth
      • Login page GET & POST
    • /webauthn/register
      • Register webauthn GET & POST
    • /webauthn/delete/$id
      • Deletes integrations?
  • Integrates with https://developer.android.com/training/safetynet/attestation
  • Flow:
    • User logs in via regular method
    • User registers a security key (login required first to tie the security key information to the user)
    • Device asks user what security key they want to use and authenticates against it
    • Server receives info and connects it to the user
    • Next time user logs in it’s treated as the 2FA method (if 2FA fails act as if login never happened)
      • This package seems to struggle with the fingerprint method (“Requires GMP or bcmath extension”), could just be an environment issue with heroku
    • (Note: should also be able to use it for password less login, but more research is required for that)
• https://medium.com/weekly-webtips/laravel-webauthn-the-super-easy-way-d3d93cb9ed14
  • https://itnext.io/laravel-login-users-with-their-fingerprints-5161ecdca63b
  • https://github.com/DarkGhostHunter/Larapass
  • https://laravel-news.com/web-authentication-for-laravel
• https://webauthn.guide/