Multi Factor Authentication

Nobody has claimed this yet.

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 https://github.com/laravel/fortify/issues/22 when the feature is completed

WebAuthN flow:
Tired of passwords

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
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://webauthn.guide/

No implementation files, tests, or entry points are named; begin by reviewing the existing authentication architecture and the Laravel Fortify and Jetstream references listed in the issue. Compare the proposed provider/driver, recovery-code, encrypted-secret, and password-reset requirements with the current system. Done requires an agreed scope and design before implementation can be started.

Written by the indexing model from the issue text.

Description

Contributor guide

First steps

Research direction

Assessment