Populating initial roles in a production database

Question

When deploying an app to production for the first time (for example using Asp.Net Identity for user management and Entity Framework Core for an ORM) and there is a need for an initial administrator account to be created after it is deployed, what is the best way to achieve this securely? All of the options I can think of below are not perfect:

1. Use a DbSeed class to seed an administrator role and user at startup if the migrated database has no roles / users already (this has the downside of both role names and user password being hardcoded in the app itself
2. Run a script to generate SQL from entity framework migrations, amend the script to seed the admin user, and then apply the script to a production database (again user password now exists in the generated SQL script)
3. Accessing the database in production, and manually adding a user and role to the AspNetUsers and AspNetRoles table manually (for this option though, I don't know of a way you can insert a correctly hashed+salted password, without making some known password in a development database and copying it into production, but this seems clunky)

Is there any standard way of doing this I may have missed?

Answer 1

The pattern will depend on your use case, and how you expect the app to be deployed. You need to consider the risk profile of the setup environment.

In general, hard coded values are a bad idea, particularly for anything network facing. There are also some issues with automatic "no users" detection as a trigger - as it makes deleting all the existing users into an attack vector.

Common models include:

• If using SSO, federated auth or similar, rely on the authentication platforms mechanisms to deal with this if possible.

• Installer setup - some part of the installation / deployment process enbles setting an initial credential.

• "first run" - when the app / site is first accessed, some kind of setup process runs, allowing you to configure the first user and any other initial setup.

• log token - the application genenerates some kind of temp credential and logs it when it first starts - this allows anyone with log access to login with it. May be used to build on security of "first run".

• enable temp user in config- define a user credential in a static config file, which is intended to be used to setup, then removed.

In any case where a temp credential is used, it should be diminished as far as possible - ie. single use, time restricted, least privillage.