* add user interface for managing 2fa
* update user schema with 2fa columns
* implement two factor check during login
* Use pyotp for validating TOTP codes
* also implements resynchronisation support via `pyotp`'s `valid_window option
* Update API route naming, update setup page
* Rename /two-factor-auth/ => /2fa/
* Nest totp routes under /2fa/totp/
* Update ids and methods in panel to allow for different setup types
* Autofocus otp input when logging in, update layout
* Extract TOTPStrategy class to totp.py
* this decouples `TOTP` validation and storage logic from `auth` and moves it to `totp`
* reduce `pyotp.validate#valid_window` from `2` to `1`
* Update OpenApi docs, rename /2fa/ => /mfa/
* Decouple totp from users table by moving to totp_credentials table
* this allows implementation of other mfa schemes in the future (webauthn)
* also makes key management easier and enforces one totp credentials per user on db-level
* Add sqlite migration
* Rename internal validate_two_factor_secret => validate_two_factor_secret
* conn.close() if mru_token update can't .commit()
* Address review feedback, thanks @hija
* Use hmac.compare_digest() to compare mru_token
* Safeguard against empty mru_token column
* hmac.compare_digest() expects arguments of type string, make sure we don't pass None
* Currently, this cannot happen but we might not want to store `mru_token` during setup
* Do not log failed login attempts for MissingToken errors
* Due to the way that the /login UI works, this persists at least one failed login each time a user logs into the admin panel. This in turn triggers fail2ban at some point.
* Add TOTP secret to user_key hash
thanks @downtownallday
* this invalidates all user_keys after TOTP status is changed for user
* after changing TOTP state, a login is required
* due to the forced login, we can't and don't need to store the code used for setup in `mru_code`
* Typo
* Reorganize the MFA backend methods
* Reorganize MFA front-end and add label column
* Fix handling of bad input when enabling mfa
* Update openAPI docs
* Remove unique key constraint on foreign key user_id in mfa table
* Don't expose mru_token and secret for enabled mfas over HTTP
* Only update mru_token for matched mfa row
* Exclude mru_token in user key hash
* Rename tools/mail.py to management/cli.py
* Add MFA list/disable to the management CLI so admins can restore access if MFA device is lost
Co-authored-by: Joshua Tauberer <jt@occams.info>
v0.50 (September 25, 2020)
--------------------------
Setup:
* When upgrading from versions before v0.40, setup will now warn that ownCloud/Nextcloud data cannot be migrated rather than failing the installation.
Mail:
* An MTA-STS policy for incoming mail is now published (in DNS and over HTTPS) when the primary hostname and email address domain both have a signed TLS certificate installed, allowing senders to know that an encrypted connection should be enforced.
* The per-IP connection limit to the IMAP server has been doubled to allow more devices to connect at once, especially with multiple users behind a NAT.
DNS:
* autoconfig and autodiscover subdomains and CalDAV/CardDAV SRV records are no longer generated for domains that don't have user accounts since they are unnecessary.
* IPv6 addresses can now be specified for secondary DNS nameservers in the control panel.
TLS:
* TLS certificates are now provisioned in groups by parent domain to limit easy domain enumeration and make provisioning more resilient to errors for particular domains.
Control Panel:
* The control panel API is now fully documented at https://mailinabox.email/api-docs.html.
* User passwords can now have spaces.
* Status checks for automatic subdomains have been moved into the section for the parent domain.
* Typo fixed.
Web:
* The default web page served on fresh installations now adds the `noindex` meta tag.
* The HSTS header is revised to also be sent on non-success responses.
* this allows implementation of other mfa schemes in the future (webauthn)
* also makes key management easier and enforces one totp credentials per user on db-level
- The MIAB version check regularly fails at 03:00, presumably because a
large portion of installations is checking mailinabox.email at the same
time.
- At installation time, the time of the nightly clock is configured to
run at a random minute after 03:00, but before 04:00.
- Users might expect the nightly tasks to be over at a certain time and
run their own custom tasks afterwards. This could thus interfere with
custom backup routines.
- This breaks reproducibility of the installation process.
- Users might also be surprised by the nightly task time changing after
updating MIAB.
