Allow changing password for default [email protected] user before first start

[e-g1gor]

Describe the feature you'd like

Initial password for default admin should be configurable somehow, maybe via .env file, like

DEFAULT_ADMIN_PASSWORD=xxx

Describe the benefits this would bring to existing BookStack users

There is default migration, that creates admin user with easily brutable credentials.
It allows to easily bruteforce admin access to newly deployed services - for as long as someone do not change password manually.

If this service is being deployed to domain that attracted attention of hackers - they may perform atack immediately, before default password will be changed.

Can the goal of this request already be achieved via other means?

By tweaking original migration -

BookStack/database/migrations/2014_10_12_000000_create_users_table.php

Line 28 in ad60517

'password' => bcrypt('password'),

Have you searched for an existing open/closed issue?

• I have searched for existing issues and none cover my fundemental request

How long have you been using BookStack?

Not using yet, just scoping

Additional context

No response

[ssddanbrown]

Thanks for the request @e-g1gor.

Somewhat related to #3946 and #3947.
As per my comment in #3947, I'd ideally like to change how the initial account is created, but I just need to ensure it works for all existing use-cases & installation options without too much pain, and requires some coordination across hosting options and documentation.

I may start to think about intended route on for the current maintenance release cycle.

From my view I'm not too worried about the "bruteforce" scenario here (although no need to bruteforce where it's using a single default option), I think that's rare and can be mitigated via following our guidance, networking and other controls if that really is a concern, my main concern is just with folks not changing the default credentials.

[ssddanbrown]

I've now opened #4575 to put forward a multi-stage plan in changing the default admin account handling, with an aim to provide a smooth transition and work with downstream setup/install/guide providers.
I'll therefore close this in favour of centralising things to that issue.

Thanks again @e-g1gor.