5 Differences from the upstream API implementation

Daniel García edited this page 2021-04-27 23:41:57 +02:00

Table of Contents

• Inviting users into organization
• With SMTP enabled
• Without SMTP enabled
• Running on unencrypted connection

Inviting users into organization

With SMTP enabled

Invited users will receive an email containing a link that is valid for 5 days. Upon clicking the link, users can choose to create an account or log in. New users will need to create a new account; existing users who are being invited to a new organization will simply need to log in. After either step, they will show up as "Accepted" in the admin interface, and will be added to the organization when an orgnization admin confirms them.

Without SMTP enabled

The invited users won't get an invitation email; instead all already registered users will appear in the interface as if they already accepted the invitation. Organization admin then just needs to confirm them to be proper Organization members and to give them access to the shared secrets.

Invited users that aren't registered yet will show up in the Organization admin interface as "Invited". At the same time an invitation record is created that allows the users to register even if user registration is disabled. (unless you disable this functionality) They will automatically become "Accepted" once they register. From there Organization admin can confirm them to give them access to Organization.

Running on unencrypted connection

It is strongly recommended to run vaultwarden service over HTTPS. However the server itself while supporting it does not strictly require such setup. This makes it a bit easier to spin up the service in cases where you can generally trust the connection (internal and secure network, access over VPN,..) or when you want to put the service behind HTTP proxy, that will do the encryption on the proxy end.

Running over HTTP is still reasonably secure provided you use really strong master password and that you avoid using web Vault over connection that is vulnerable to MITM attacks where attacker could inject javascript into your interface. However some forms of 2FA might not work in this setup and Vault doesn't work in this configuration in Chrome.

FAQs

1. FAQs
2. Audits

Container Image Usage

1. Which container image to use
2. Starting a container
3. Updating the vaultwarden image
4. Using Docker Compose
5. Using Podman

Deployment

1. Building your own docker image
2. Building binary
3. Pre-built binaries
4. Third-party packages
5. Deployment examples
6. Proxy examples
7. Logrotate example

HTTPS

1. Enabling HTTPS
2. Running a private vaultwarden instance with Let's Encrypt certs

Configuration

1. Overview
2. Disable registration of new users
3. Disable invitations
4. Enabling admin page
5. Disable the admin token
6. Enabling WebSocket notifications
7. Enabling Mobile Client push notification
8. Enabling U2F and FIDO2 WebAuthn authentication
9. Enabling YubiKey OTP authentication
10. Changing persistent data location
11. Changing the API request size limit
12. Changing the number of workers
13. SMTP configuration
14. Translating the email templates
15. Password hint display
16. Disabling or overriding the Vault interface hosting
17. Logging
18. Creating a systemd service
19. Syncing users from LDAP
20. Using an alternate base dir (subdir/subpath)
21. Other configuration

Database

1. Using the MariaDB (MySQL) Backend
2. Using the PostgreSQL Backend
3. Running without WAL enabled
4. Migrating from MariaDB (MySQL) to SQLite

Security

1. Hardening Guide
2. Fail2Ban Setup
3. Fail2Ban + ModSecurity + Traefik + Docker

Backup

1. General (not docker)

Other Information

1. Importing data from Keepass or KeepassX
2. Backing up your vault
3. Differences from the upstream API implementation
4. Supporting upstream development
5. Caddy 2.x with Cloudflare DNS