2020-02-29 07:43:59 +07:00
|
|
|
---
|
2022-06-15 14:51:47 +07:00
|
|
|
title: "Time-based One Time Password"
|
|
|
|
description: "Configuring the Time-based One Time Password Second Factor Method."
|
|
|
|
lead: "Authelia supports utilizing time-based one-time passwords as a 2FA method."
|
|
|
|
date: 2022-03-20T12:52:27+11:00
|
|
|
|
draft: false
|
|
|
|
images: []
|
|
|
|
menu:
|
|
|
|
configuration:
|
|
|
|
parent: "second-factor"
|
|
|
|
weight: 103300
|
|
|
|
toc: true
|
|
|
|
aliases:
|
|
|
|
- /c/totp
|
|
|
|
- /docs/configuration/one-time-password.html
|
2020-02-29 07:43:59 +07:00
|
|
|
---
|
|
|
|
|
2022-06-15 14:51:47 +07:00
|
|
|
The OTP method *Authelia* uses is the Time-Based One-Time Password Algorithm (TOTP) [RFC6238] which is an extension of
|
|
|
|
HMAC-Based One-Time Password Algorithm (HOTP) [RFC4226].
|
2020-02-29 07:43:59 +07:00
|
|
|
|
2022-06-15 14:51:47 +07:00
|
|
|
You have the option to tune the settings of the TOTP generation, and you can see a full example of TOTP configuration
|
|
|
|
below, as well as sections describing them.
|
|
|
|
|
|
|
|
Keep in mind the default settings are chosen for compatibility. Many applications do not support digits other than 6,
|
|
|
|
and many only support SHA1.
|
2020-02-29 07:43:59 +07:00
|
|
|
|
2021-04-11 18:25:03 +07:00
|
|
|
## Configuration
|
2022-06-15 14:51:47 +07:00
|
|
|
|
2020-04-11 11:46:07 +07:00
|
|
|
```yaml
|
|
|
|
totp:
|
2022-03-03 18:20:43 +07:00
|
|
|
disable: false
|
2020-04-11 11:46:07 +07:00
|
|
|
issuer: authelia.com
|
2021-12-01 19:11:29 +07:00
|
|
|
algorithm: sha1
|
|
|
|
digits: 6
|
2020-04-11 11:46:07 +07:00
|
|
|
period: 30
|
|
|
|
skew: 1
|
2022-04-08 06:01:01 +07:00
|
|
|
secret_size: 32
|
2020-04-11 11:46:07 +07:00
|
|
|
```
|
|
|
|
|
2021-04-11 18:25:03 +07:00
|
|
|
## Options
|
|
|
|
|
2022-03-03 18:20:43 +07:00
|
|
|
### disable
|
2022-06-15 14:51:47 +07:00
|
|
|
|
|
|
|
{{< confkey type="boolean" default="false" required="no" >}}
|
2022-03-03 18:20:43 +07:00
|
|
|
|
|
|
|
This disables One-Time Password (TOTP) if set to true.
|
|
|
|
|
2021-04-11 18:25:03 +07:00
|
|
|
### issuer
|
2022-06-15 14:51:47 +07:00
|
|
|
|
|
|
|
{{< confkey type="string" default="Authelia" required="no" >}}
|
2020-03-25 08:48:20 +07:00
|
|
|
|
|
|
|
Applications generating one-time passwords usually display an issuer to
|
|
|
|
differentiate applications registered by the user.
|
|
|
|
|
|
|
|
Authelia allows customisation of the issuer to differentiate the entry created
|
2020-02-29 07:43:59 +07:00
|
|
|
by Authelia from others.
|
|
|
|
|
2021-12-01 19:11:29 +07:00
|
|
|
### algorithm
|
2022-06-15 14:51:47 +07:00
|
|
|
|
|
|
|
{{< confkey type="string" default="sha1" required="no" >}}
|
|
|
|
|
|
|
|
*__Important Note:__ Many TOTP applications do not support this option. It is strongly advised you find out which
|
2021-12-01 19:11:29 +07:00
|
|
|
applications your users use and test them before changing this option. It is insufficient to test that the application
|
2022-06-15 14:51:47 +07:00
|
|
|
can add the key, it must also authenticate with Authelia as some applications silently ignore these options. Bitwarden
|
|
|
|
is the only one that has been tested at this time. If you'd like to contribute to documenting support for this option
|
|
|
|
please see [Issue 2650](https://github.com/authelia/authelia/issues/2650).*
|
2020-03-25 08:48:20 +07:00
|
|
|
|
2021-12-01 19:11:29 +07:00
|
|
|
The algorithm used for the TOTP key.
|
|
|
|
|
|
|
|
Possible Values (case-insensitive):
|
2022-06-15 14:51:47 +07:00
|
|
|
|
|
|
|
* `sha1`
|
|
|
|
* `sha256`
|
|
|
|
* `sha512`
|
2021-12-01 19:11:29 +07:00
|
|
|
|
|
|
|
Changing this value only affects newly registered TOTP keys. See the [Registration](#registration) section for more
|
|
|
|
information.
|
|
|
|
|
|
|
|
### digits
|
2022-06-15 14:51:47 +07:00
|
|
|
|
|
|
|
{{< confkey type="integer" default="6" required="no" >}}
|
|
|
|
|
|
|
|
*__Important Note:__ Some TOTP applications do not support this option. It is strongly advised you find out which
|
2021-12-01 19:11:29 +07:00
|
|
|
applications your users use and test them before changing this option. It is insufficient to test that the application
|
|
|
|
can add the key, it must also authenticate with Authelia as some applications silently ignore these options. Bitwarden
|
|
|
|
is the only one that has been tested at this time. If you'd like to contribute to documenting support for this option
|
2022-06-15 14:51:47 +07:00
|
|
|
please see [Issue 2650](https://github.com/authelia/authelia/issues/2650).*
|
2021-12-01 19:11:29 +07:00
|
|
|
|
2022-06-15 14:51:47 +07:00
|
|
|
The number of digits a user needs to input to perform authentication. It's generally not recommended for this to be
|
2021-12-01 19:11:29 +07:00
|
|
|
altered as many TOTP applications do not support anything other than 6. What's worse is some TOTP applications allow
|
|
|
|
you to add the key, but do not use the correct number of digits specified by the key.
|
2020-03-25 08:48:20 +07:00
|
|
|
|
2021-12-01 19:11:29 +07:00
|
|
|
The valid values are `6` or `8`.
|
|
|
|
|
|
|
|
Changing this value only affects newly registered TOTP keys. See the [Registration](#registration) section for more
|
|
|
|
information.
|
2020-03-25 08:48:20 +07:00
|
|
|
|
2021-04-11 18:25:03 +07:00
|
|
|
### period
|
2022-06-15 14:51:47 +07:00
|
|
|
|
|
|
|
{{< confkey type="integer" default="30" required="no" >}}
|
|
|
|
|
|
|
|
The period of time in seconds between key rotations or the time element of TOTP. Please see the
|
2021-12-01 19:11:29 +07:00
|
|
|
[input validation](#input-validation) section for how this option and the [skew](#skew) option interact with each other.
|
|
|
|
|
|
|
|
It is recommended to keep this value set to 30, the minimum is 15.
|
2020-03-25 08:48:20 +07:00
|
|
|
|
2021-12-01 19:11:29 +07:00
|
|
|
Changing this value only affects newly registered TOTP keys. See the [Registration](#registration) section for more
|
|
|
|
information.
|
2021-04-11 18:25:03 +07:00
|
|
|
|
|
|
|
### skew
|
2022-06-15 14:51:47 +07:00
|
|
|
|
|
|
|
{{< confkey type="integer" default="1" required="no" >}}
|
|
|
|
|
|
|
|
The number of one time passwords either side of the current valid one time password that should also be considered valid.
|
2021-12-01 19:11:29 +07:00
|
|
|
The default of 1 results in 3 one time passwords valid. A setting of 2 would result in 5. With the default period of 30
|
2022-06-15 14:51:47 +07:00
|
|
|
this would result in 90 and 150 seconds of valid one time passwords respectively. Please see the
|
2021-12-01 19:11:29 +07:00
|
|
|
[input validation](#input-validation) section for how this option and the [period](#period) option interact with each
|
|
|
|
other.
|
2020-03-25 08:48:20 +07:00
|
|
|
|
2021-12-01 19:11:29 +07:00
|
|
|
Changing this value affects all TOTP validations, not just newly registered ones.
|
2021-09-17 11:44:35 +07:00
|
|
|
|
2022-04-08 06:01:01 +07:00
|
|
|
### secret_size
|
2022-06-15 14:51:47 +07:00
|
|
|
|
|
|
|
{{< confkey type="integer" default="32" required="no" >}}
|
|
|
|
|
|
|
|
The length in bytes of generated shared secrets. The minimum is 20 (or 160 bits), and the default is 32 (or 256 bits).
|
2022-04-08 06:01:01 +07:00
|
|
|
In most use cases 32 is sufficient. Though some authenticators may have issues with more than the minimum. Our minimum
|
|
|
|
is the recommended value in [RFC4226], though technically according to the specification 16 bytes (or 128 bits) is the
|
|
|
|
minimum.
|
|
|
|
|
2021-12-01 19:11:29 +07:00
|
|
|
## Registration
|
2022-06-15 14:51:47 +07:00
|
|
|
|
|
|
|
When users register their TOTP device for the first time, the current [issuer](#issuer), [algorithm](#algorithm), and
|
2021-12-01 19:11:29 +07:00
|
|
|
[period](#period) are used to generate the TOTP link and QR code. These values are saved to the database for future
|
2022-06-15 14:51:47 +07:00
|
|
|
validations.
|
2021-09-17 11:44:35 +07:00
|
|
|
|
2022-06-15 14:51:47 +07:00
|
|
|
This means if the configuration options are changed, users will not need to regenerate their keys. This functionality
|
2021-12-01 19:11:29 +07:00
|
|
|
takes effect from 4.33.0 onwards, previously the effect was the keys would just fail to validate. If you'd like to force
|
2022-06-15 14:51:47 +07:00
|
|
|
users to register a new device, you can delete the old device for a particular user by using the
|
2021-12-01 19:11:29 +07:00
|
|
|
`authelia storage totp delete <username>` command regardless of if you change the settings or not.
|
|
|
|
|
|
|
|
## Input Validation
|
2022-06-15 14:51:47 +07:00
|
|
|
|
|
|
|
The period and skew configuration parameters affect each other. The default values are a period of 30 and a skew of 1.
|
2021-12-01 19:11:29 +07:00
|
|
|
It is highly recommended you do not change these unless you wish to set skew to 0.
|
|
|
|
|
2022-04-08 06:01:01 +07:00
|
|
|
These options affect security by changing the length of time a one-time password is valid for. The formula to calculate
|
|
|
|
the effective validity period is `period + (period * skew * 2)`. For example period 30 and skew 1 would result in 90
|
2021-12-01 19:11:29 +07:00
|
|
|
seconds of validity, and period 30 and skew 2 would result in 150 seconds of validity.
|
|
|
|
|
|
|
|
## System time accuracy
|
2022-06-15 14:51:47 +07:00
|
|
|
|
2021-09-17 11:44:35 +07:00
|
|
|
It's important to note that if the system time is not accurate enough then clients will seemingly not generate valid
|
2022-06-15 14:51:47 +07:00
|
|
|
passwords for TOTP. Conversely this is the same when the client time is not accurate enough. This is due to the
|
|
|
|
Time-based One Time Passwords being time-based.
|
2021-09-17 11:44:35 +07:00
|
|
|
|
2022-06-15 14:51:47 +07:00
|
|
|
Authelia by default checks the system time against an [NTP server](../miscellaneous/ntp.md) on startup. This helps to
|
|
|
|
prevent a time synchronization issue on the server being an issue. There is however no effective and reliable way to
|
|
|
|
check the clients.
|
2021-12-01 19:11:29 +07:00
|
|
|
|
|
|
|
## Encryption
|
2022-06-15 14:51:47 +07:00
|
|
|
|
|
|
|
The TOTP secret is [encrypted](../storage/introduction.md#encryption_key) in the database in version 4.33.0 and above.
|
|
|
|
This is so a user having access to only the database cannot easily compromise your two-factor authentication method.
|
2021-12-01 19:11:29 +07:00
|
|
|
|
|
|
|
This may be inconvenient for some users who wish to export TOTP keys from Authelia to other services. As such there is
|
|
|
|
a command specifically for exporting TOTP configurations from the database. These commands require the configuration or
|
|
|
|
at least a minimal configuration that has the storage backend connection details and the encryption key.
|
|
|
|
|
|
|
|
Export in [Key URI Format](https://github.com/google/google-authenticator/wiki/Key-Uri-Format):
|
|
|
|
|
2022-06-15 14:51:47 +07:00
|
|
|
```bash
|
|
|
|
authelia storage totp export --format uri
|
2021-12-01 19:11:29 +07:00
|
|
|
```
|
|
|
|
|
|
|
|
Export as CSV:
|
|
|
|
|
2022-06-15 14:51:47 +07:00
|
|
|
```bash
|
|
|
|
authelia storage totp export --format csv
|
2021-12-01 19:11:29 +07:00
|
|
|
```
|
|
|
|
|
|
|
|
Help:
|
|
|
|
|
2022-06-15 14:51:47 +07:00
|
|
|
```bash
|
|
|
|
authelia storage totp export --help
|
2021-12-01 19:11:29 +07:00
|
|
|
```
|
2022-04-08 06:01:01 +07:00
|
|
|
|
2022-06-15 14:51:47 +07:00
|
|
|
[RFC4226]: https://www.rfc-editor.org/rfc/rfc4226.html
|
|
|
|
[RFC6238]: https://www.rfc-editor.org/rfc/rfc6238.html
|