-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Description
This issue lays out the plan to change the way that the default admin access is granted on new instances.
Currently, a default admin account is created via migrations with the "[email protected]" email, and password
password.
There are two main goals of this change:
- Stop using the
[email protected]
email address. - Stop using predetermined/known credentials, causing a security issue if left unchanged.
While we could make changes easily and directly just thinking about BookStack itself, we need to think about the ways BookStack is hosted/provided to ensure we don't break the setup/install flows in various use-cases.
Plan
Over a range of feature releases we'll make changes to work toward this incrementally.
- Expand options of the
create-admin
command. - Notify BookStack hosting/service providers and projects, with advisory of options.
- Remove the default user creation.
There probably should be a couple of feature releases' worth of time between 1 and 3.
Create admin command changes
To provide options, and potentially seamless routes to handle these changes, we'll update the create-admin
command with extra options:
--first-admin
: This option will create the admin user, only if there are no pre-existing admin users in the system. If there's only the default admin account ([email protected]
with default password), this will instead update that account with the provided details. If this does not result in an admin account being created/updated, this will return an error status code so the caller can acknowledge if the account can be used.
--generate-password
: This option will generate a random password for the user and return it via stdout on the command line. This should be the only output when this option is used.
With the --first-admin
option added, setup providers can migrate to using this option after it's released, but before default user creation is removed, so a seamless transition can be achieved. You could even use the existing default credentials to switch to the new system without any user-facing change (could help simply or delay changes but not advisable since won't help toward main goals). The behaviour of this option means it can be ran via init scripts, without needing to query BookStack, or the environment, first to see if this is a fresh system without a (or with default) admin user.
The password gen option, combined with the first admin option, can open some options to providers to help migrate to a more secure setup.
Official guidance/script changes
On the official side of things, we'll need to:
- Change our currently supported install scripts to create a user with a random password, then output to user.
- Update our docs with this noted in our install and script guidance.
- Pin comments to our install videos to advise of this change.
- Probably worth creating a post in the Subreddit for SEO purposes, for when folks search for default credentials.
We can update our scripts after the initial addition of the command options.
These can then be used as an example for others to update their scripts/setups with.
Setup Providers to Notify
We'll need to notify these folks when the time comes (After commands have been implemented).
This list will be used for tracking when the time comes.
Please don't notify these projects/groups/people yet!
If I've missed a BookStack hosting provider/project, please let me know via a comment below.
- Linuxserver docker image team
- Solidnerd docker image team
- Homeassistant addon team
- Cloudron
- Uberspace
- Stellar Hosted
- Cloudabove
- Alwaysdata
- Pikapods
- YunoHost
- Elestio
- Nexxwave
- Easypanel
- Marius Hosting Synology guide - Depends on Linuxserver changes
- ServerGroup AMI? - Seems dodgy from their website
- Intuz AMI? Have been know to delay on updates.
- Archlinux AUR setup team
Questionables
- Should we show specific login help text if old default user credentials are attempted, when no users exist in the system (after stage 3). Seems like it'd be a good help but need to ponder if there's a security consideration there.
- Have any groups/teams been missed in the above?
- Do the proposed changes not suit particular flows/projects/install-methods?