6a979f4f52
* 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> |
||
|---|---|---|
| api | ||
| conf | ||
| management | ||
| setup | ||
| tests | ||
| tools | ||
| .editorconfig | ||
| .gitignore | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
| security.md | ||
| Vagrantfile | ||
Mail-in-a-Box
By @JoshData and contributors.
Mail-in-a-Box helps individuals take back control of their email by defining a one-click, easy-to-deploy SMTP+everything else server: a mail server in a box.
Please see https://mailinabox.email for the project's website and setup guide!
Our goals are to:
- Make deploying a good mail server easy.
- Promote decentralization, innovation, and privacy on the web.
- Have automated, auditable, and idempotent configuration.
- Not make a totally unhackable, NSA-proof server.
- Not make something customizable by power users.
Additionally, this project has a Code of Conduct, which supersedes the goals above. Please review it when joining our community.
In The Box
Mail-in-a-Box turns a fresh Ubuntu 18.04 LTS 64-bit machine into a working mail server by installing and configuring various components.
It is a one-click email appliance. There are no user-configurable setup options. It "just works."
The components installed are:
- SMTP (postfix), IMAP (Dovecot), CardDAV/CalDAV (Nextcloud), and Exchange ActiveSync (z-push) servers
- Webmail (Roundcube), mail filter rules (thanks to Roundcube and Dovecot), and email client autoconfig settings (served by nginx)
- Spam filtering (spamassassin) and greylisting (postgrey)
- DNS (nsd4) with SPF, DKIM (OpenDKIM), DMARC, DNSSEC, DANE TLSA, MTA-STS, and SSHFP policy records automatically set
- TLS certificates are automatically provisioned using Let's Encrypt for protecting https and all of the other services on the box
- Backups (duplicity), firewall (ufw), intrusion protection (fail2ban), and basic system monitoring (munin)
It also includes system management tools:
- Comprehensive health monitoring that checks each day that services are running, ports are open, TLS certificates are valid, and DNS records are correct
- A control panel for adding/removing mail users, aliases, custom DNS records, configuring backups, etc.
- An API for all of the actions on the control panel
It also supports static website hosting since the box is serving HTTPS anyway. (To serve a website for your domains elsewhere, just add a custom DNS "A" record in you Mail-in-a-Box's control panel to point domains to another server.)
For more information on how Mail-in-a-Box handles your privacy, see the security details page.
Installation
See the setup guide for detailed, user-friendly instructions.
For experts, start with a completely fresh (really, I mean it) Ubuntu 18.04 LTS 64-bit machine. On the machine...
Clone this repository:
$ git clone https://github.com/mail-in-a-box/mailinabox
$ cd mailinabox
Optional: Download Josh's PGP key and then verify that the sources were signed by him:
$ curl -s https://keybase.io/joshdata/key.asc | gpg --import
gpg: key C10BDD81: public key "Joshua Tauberer <jt@occams.info>" imported
$ git verify-tag v0.50
gpg: Signature made ..... using RSA key ID C10BDD81
gpg: Good signature from "Joshua Tauberer <jt@occams.info>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 5F4C 0E73 13CC D744 693B 2AEA B920 41F4 C10B DD81
You'll get a lot of warnings, but that's OK. Check that the primary key fingerprint matches the fingerprint in the key details at https://keybase.io/joshdata and on his personal homepage. (Of course, if this repository has been compromised you can't trust these instructions.)
Checkout the tag corresponding to the most recent release:
$ git checkout v0.50
Begin the installation.
$ sudo setup/start.sh
For help, DO NOT contact Josh directly --- I don't do tech support by email or tweet (no exceptions).
Post your question on the discussion forum instead, where maintainers and Mail-in-a-Box users may be able to help you.
Note that while we want everything to "just work," we can't control the rest of the Internet. Other mail services might block or spam-filter email sent from your Mail-in-a-Box. This is a challenge faced by everyone who runs their own mail server, with or without Mail-in-a-Box. See our discussion forum for tips about that.
Contributing and Development
Mail-in-a-Box is an open source project. Your contributions and pull requests are welcome. See CONTRIBUTING to get started.
The Acknowledgements
This project was inspired in part by the "NSA-proof your email in 2 hours" blog post by Drew Crawford, Sovereign by Alex Payne, and conversations with @shevski, @konklone, and @GregElin.
Mail-in-a-Box is similar to iRedMail and Modoboa.
The History
- In 2007 I wrote a relatively popular Mozilla Thunderbird extension that added client-side SPF and DKIM checks to mail to warn users about possible phishing: add-on page, source.
- In August 2013 I began Mail-in-a-Box by combining my own mail server configuration with the setup in "NSA-proof your email in 2 hours" and making the setup steps reproducible with bash scripts.
- Mail-in-a-Box was a semifinalist in the 2014 Knight News Challenge, but it was not selected as a winner.
- Mail-in-a-Box hit the front page of Hacker News in April 2014, September 2014, May 2015, and November 2016.
- FastCompany mentioned Mail-in-a-Box a roundup of privacy projects on June 26, 2015.