Download the PHP package laragear/two-factor without Composer
On this page you can find all versions of the php package laragear/two-factor. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download laragear/two-factor
More information about laragear/two-factor
Files in laragear/two-factor
Package two-factor
Short Description On-premises 2FA Authentication for out-of-the-box.
License MIT
Informations about the package two-factor
Two Factor
On-premises Two-Factor Authentication for all your users out of the box.
This package enables TOTP authentication using 6 digits codes. No need for external APIs.
[!TIP]
Want to authenticate users with Passkeys? Check out Laragear WebAuthn.
Become a sponsor
Your support allows me to keep this package free, up-to-date and maintainable. Alternatively, you can spread the word!
Requirements
- Laravel 10 or later
Installation
Fire up Composer and require this package in your project.
composer require laragear/two-factor
That's it.
How this works
This package adds a Contract to detect if a user, after the credentials are deemed valid, should use Two-Factor Authentication as a second layer of authentication.
It includes a custom view and a helper to handle the Two-Factor authentication itself during login attempts.
Works without middleware or new guards, but you can go full manual if you want.
Set up
- First, install the migration, translations, views and config into your application, with the
two-factor:install
Artisan command.
[!TIP]
You can table name.
After that, you may migrate your table like always through the Artisan command.
- Add the
TwoFactorAuthenticatable
contract and theTwoFactorAuthentication
trait to the User model, or any other model you want to make Two-Factor Authentication available.
[!TIP]
The contract is used to identify the model using Two-Factor Authentication, while the trait conveniently implements the methods required to handle it.
That's it. You're now ready to use 2FA in your application.
Enabling Two-Factor Authentication
To enable Two-Factor Authentication for the User, he must sync the Shared Secret between its Authenticator app and the application.
[!TIP]
Free Authenticator Apps, in no particular order, are iOS Authenticator, FreeOTP, Authy, 2FAS, 2Stable Authenticator, Step-two, BinaryRoot Authenticator, Google Authenticator, and Microsoft Authenticator, to name a few.
To start, generate the needed data using the createTwoFactorAuth()
method. This returns a serializable Shared Secret that you can show to the User as a string or QR Code (encoded as SVG) in your view.
[!TIP]
When you use
createTwoFactorAuth()
on someone with Two-Factor Authentication already enabled, the previous data becomes permanently invalid. This ensures a User never has two Shared Secrets enabled at any given time.
Then, the User must confirm the Shared Secret with a Code generated by their Authenticator app. The confirmTwoFactorAuth()
method will automatically enable it if the code is valid.
If the User doesn't issue the correct Code, the method will return false
. You can tell the User to double-check its device's timezone, or create another Shared Secret with createTwoFactorAuth()
.
Recovery Codes
Recovery Codes are automatically generated each time the Two-Factor Authentication is enabled. By default, a Collection of ten one-use 8-characters codes are created.
You can show them using getRecoveryCodes()
.
You're free on how to show these codes to the User, but ensure you show them at least one time after a successfully enabling Two-Factor Authentication, and ask him to print them somewhere.
[!TIP]
These Recovery Codes are handled automatically when the User sends it instead of a TOTP code. If it's a recovery code, the package will use and mark it as invalid, so it can't be used again.
The User can generate a fresh batch of codes using generateRecoveryCodes()
, which replaces the previous batch.
[!IMPORTANT]
If the User depletes his recovery codes without disabling Two-Factor Authentication, or Recovery Codes are deactivated, he may be locked out forever without his Authenticator app. Ensure you have countermeasures in these cases, like recovery emails.
Custom Recovery Codes
While it's not recommended, as the included logic will suffice for the vast majority of situations, you can create your own generator for recovery codes. Just add a callback using the generateRecoveryCodesUsing()
of the TwoFactorAuthentication
model.
This method receives a callback that should return a random alphanumeric code, and will be invoked on each code to generate.
Logging in
The easiest way to login users in your application is to use the Auth2FA
facade. It comes with everything you would need to handle a user that requires a 2FA Code:
- Only works if the user has 2FA enabled.
- Shows a custom form if the 2FA code is required.
- Credentials are encrypted and flashed in the session to re-use them.
In your Login Controller, use the Auth2FA::attempt()
method with the credentials. If the user requires a 2FA Code, it will automatically stop the authentication and show a form to use it.
You can blatantly copy-and-paste this code in your log in controller:
You can further customize how to handle the 2FA code authentication procedure with the following fluent methods:
Method | Description |
---|---|
guard($guard) | The guard to use for authentication. Defaults to the application default (web ). |
view($view) | Return a custom view to handle the 2FA Code retry. |
redirect($route) | Redirect to a location to handle the 2FA Code retry. |
message($message) | Return a custom message when the 2FA code fails or is not present. |
input($input) | Sets the input where the TOTP code is in the request. Defaults to 2fa_code . |
sessionKey($key) | The key used to flash the encrypted credentials. Defaults to _2fa_login . |
For example, we can change the message to show and the input to use from the login form.
[!TIP]
- For Laravel UI, override the
attemptLogin()
method to replace the default guard attempt withAuth2FA::attempt()
andvalidateLogin
method to wrap in theif ($request->isNotFilled('2fa_code'))
statement in your Login controller.- For Laravel Breeze, you may need to extend the
LoginRequest::authenticate()
call.- For Laravel Fortify and Jetstream, you may need to set a custom callback with the
Fortify::authenticateUsing()
method.
Alternatively, you may use Auth::attemptWhen()
with TwoFactor helper methods, which returns a callback to check if the user needs a 2FA Code before proceeding using TwoFactor::hasCode()
.
You can use the hasCodeOrFails()
method that does the same, but throws a validation exception, which is handled gracefully by the framework. It even accepts a custom message in case of failure, otherwise a default translation line will be used.
Determining Safe Device bypass
When the user is under a safe device, which is determined by cookie, no 2FA code will be required to log in. To check if this was the case on the current request, use the wasTwoFactorBypassedBySafeDevice()
method on the user.
Deactivation
You can deactivate Two-Factor Authentication for a given User using the disableTwoFactorAuth()
method. This will automatically invalidate the authentication data, allowing the User to log in with just his credentials.
Events
The following events are fired in addition to the default Authentication events.
TwoFactorEnabled
: An User has enabled Two-Factor Authentication.TwoFactorRecoveryCodesDepleted
: An User has used his last Recovery Code.TwoFactorRecoveryCodesGenerated
: An User has generated a new set of Recovery Codes.TwoFactorDisabled
: An User has disabled Two-Factor Authentication.
[!TIP]
You can use
TwoFactorRecoveryCodesDepleted
to tell the User to create more Recovery Codes or mail them some more.
Middleware
TwoFactor comes with two middleware for your routes: 2fa.enabled
and 2fa.confirm
.
[!IMPORTANT]
To avoid unexpected results, middleware only act on your users models implementing the
TwoFactorAuthenticatable
contract. If a user model doesn't implement it, the middleware will bypass any 2FA logic.
Require 2FA
If you need to ensure the User has Two-Factor Authentication enabled before entering a given route, you can use the 2fa.enabled
middleware. Users who implement the TwoFactorAuthenticatable
contract and have 2FA disabled will be redirected to a route name containing the warning, which is 2fa.notice
by default.
You can implement the view easily with the one included in this package, optionally with a URL to point the user to enable 2FA:
Confirm 2FA
Much like the password.confirm
middleware, you can also ask the user to confirm entering a route by issuing a 2FA Code with the 2fa.confirm
middleware.
The middleware will redirect the user to the named route 2fa.confirm
by default, but you can change it in the first parameter. To implement the receiving routes, TwoFactor comes with the Confirm2FACodeController
and a view you can use for a quick start.
Since a user without 2FA enabled won't be asked for a code, you can combine the middleware with 2fa.require
to ensure confirming is mandatory for users without 2FA enabled.
Force confirmation
When user confirm with their TOTP code, the middleware will remember the confirmation for a set amount of time.
You may always force a confirmation, even if the user already confirmed, setting the first or second parameter as "force" or "true".
Validation
Sometimes you may want to manually trigger a TOTP validation in any part of your application for the authenticated user. You can validate a TOTP code for the authenticated user using the topt
rule.
This rule will succeed only if the user is authenticated, it has Two-Factor Authentication enabled, and the code is correct or is a recovery code.
[!TIP]
You can enforce the rule to NOT use recovery codes using
totp:code
.
Translations
TwoFactor comes with translation files that you can use immediately in your application. These are also used for the validation rule.
To add your own language, publish the translation files. These will be located in lang/vendor/two-factor
:
Configuration
To further configure the package, publish the configuration file:
You will receive the config/two-factor.php
config file with the following contents:
Cache Store
RFC 6238 states that one-time passwords shouldn't be able to be usable more than once, even if is still inside the time window. For this, we need to use the Cache to ensure the same code cannot be used again.
You can change the store to use, which it's the default used by your application, and the prefix to use as cache keys, in case of collisions.
Recovery
Recovery codes handling are enabled by default, but you can disable it. If you do, ensure Users can authenticate by other means, like sending an email with a link to a signed URL that logs him in and disables Two-Factor Authentication, or SMS.
The number and length of codes generated is configurable. 10 Codes of 8 random characters are enough for most authentication scenarios.
Safe devices
Enabling this option will allow the application to "remember" a device using a cookie, allowing it to bypass Two-Factor Authentication once a code is verified in that device. When the User logs in again in that device, it won't be prompted for a 2FA Code again.
The cookie contains a random value which is checked against a list of safe devices saved for the authenticating user. It's considered a safe device if the value matches and has not expired.
There is a limit of devices that can be saved, but usually three is enough (phone, tablet and PC). New devices will displace the oldest devices registered. Devices are considered no longer "safe" until a set amount of days.
You can change the maximum number of devices saved and the amount of days of validity once they're registered. More devices and more expiration days will make the Two-Factor Authentication less secure.
[!TIP]
When disabling Two-Factor Authentication, the list of safe devices is always flushed.
Confirmation Middleware
These control which key to use in the session for handling 2fa.confirm
middleware, and the expiration time in minutes.
Login Helper
This controls the login helper configuration, like the Blade view to render, the session key to hold the login input (like email and password), and if it should store these credentials using flash
or just put
.
About the use of flash
, you may disable it if you expect other requests during login, like it may happen with Inertia.js or Livewire, but this may keep the login input forever in the session, which in some cases it may be undesirable.
Secret length
This controls the length (in bytes) used to create the Shared Secret. While a 160-bit shared secret is enough, you can tighten or loosen the secret length to your liking.
It's recommended to use 128-bit or 160-bit because some Authenticator apps may have problems with non-RFC-recommended lengths.
TOTP Configuration
This controls TOTP code generation and verification mechanisms:
- Issuer: The name of the issuer of the TOTP. Default is the application name.
- TOTP Digits: The amount of digits to ask for TOTP code.
- TOTP Seconds: The number of seconds a code is considered valid.
- TOTP Window: Additional steps of seconds to keep a code as valid.
- TOTP Algorithm: The system-supported algorithm to handle code generation.
This configuration values are always URL-encoded and passed down to the authentication app as URI parameters:
otpauth://totp/Laravel%30taylor%40laravel.com?secret=THISISMYSECRETPLEASEDONOTSHAREIT&issuer=Laravel&label=Laravel%30taylor%40laravel.com&algorithm=SHA1&digits=6&period=30
These values are printed to each 2FA data record inside the application. Changes will only take effect for new activations.
[!WARNING]
Do not edit these parameters if you plan to use publicly available Authenticator apps, since some of them may not support non-standard configuration, like more digits, different period of seconds or other algorithms.
QR Code Configuration
This controls the size and margin used to create the QR Code, which are created as SVG.
Custom TOTP Label
You may change how your model creates a TOTP Label, which is shown to the user on its authenticator, using the getTwoFactorIssuer()
and getTwoFactorUserIdentifier()
methods of your user.
For example, we can change the issuer and identifier depending on which domain the user is visiting.
The above will render users.myapp.com:[email protected]
or admin.myapp.com:John Doe
.
Migration
This packages comes with a very hands-off approach for migrations. If you check the migration ...create_two_factor_authentications_table.php
, you will see something like this:
The schema of the table is handled internally. The addCustomColumns()
method gives you the opportunity to add more columns to the table.
If you need to execute logic after creating the table, or before dropping it, use the afterUp()
and beforeDown()
methods, respectively.
Morphs
By default, the table uses the default id of the Query Builder, Builder::$defaultMorphKeyType
. If you want to change the morph key type for only this table, you may set the $morphsType
property of the migration to uuid
or ulid
.
Custom table name
By default, the TwoFactorAuthentication
model will use the two_factor_authentications
name for the table. If you want to change the name for whatever reason, set the table using the $useTable
static property of the TwoFactorAuthentication
model. You should do this on the register()
method of your AppServiceProvider
.
Laravel Octane Compatibility
- There are no singletons using a stale application instance.
- There are no singletons using a stale config instance.
- There are no singletons using a stale request instance.
- There are no static properties written during a request.
There should be no problems using this package with Laravel Octane.
Security
When using the Login Helper, credentials are saved encrypted into the session. This can be undesirable for some applications. While this mechanism exists for convenience, you are welcome to create your own 2FA authentication flow with this package to avoid flashing the credentials.
One alternative is to use the 2fa.confirm
site-wide, and set the config key two-factor.confirm.time
to INF
.
If you discover any security related issues, please email [email protected] instead of using the issue tracker.
License
This specific package version is licensed under the terms of the MIT License, at time of publishing.
Laravel is a Trademark of Taylor Otwell. Copyright © 2011-2024 Laravel LLC.
All versions of two-factor with dependencies
ext-json Version *
laragear/meta-model Version ^1.1
laragear/meta Version 3.*
bacon/bacon-qr-code Version 2.*|3.*
paragonie/constant_time_encoding Version ^2.6 || ^3.0
illuminate/config Version 10.*|11.*
illuminate/validation Version 10.*|11.*
illuminate/database Version 10.*|11.*
illuminate/support Version 10.*|11.*
illuminate/http Version 10.*|11.*
illuminate/auth Version 10.*|11.*