Feature request for improved security: database access rights

Internals
#1

Currently, the way UserFrosting accesses the database is very risky.

When you run php bakery bake, you are prompted to provide a user ID and password that has, essentially, administrative access to the database. This is reasonable, because the Bakery may need to run Migrations that add, modify, or remove tables. The problem is, php bakery bake then saves the administrative ID and password for day-to-day use in the app/.env file. This is a significant security risk.

UserFrosting should provide the ability – no, it should require – two separate database user IDs & passwords: one for system migration, which is provided by the user through prompts (after all, you’re running the upgrade from the shell), and which is not stored anywhere; and the second which has read/write access to the tables, which is stored in a secure manner, and is used for day-to-day running of the application. This ID should not be able to add, alter, or drop tables, indexes, or other database artifacts (except temporary tables, indexes, etc. used in queries).

#2

First thing, we need to understand what the Bake command actually does. It combines setup:db , setup:smtp , debug , migrate , create-admin and build-assets into a single command. See https://learn.userfrosting.com/cli/commands#bake.

So the part where the db credentials are setup is the standalone setup:db command. The migrations are run in the standalone migrate command.

So technically, the part where db prompt is currently done is not the same part where the migration is done.

That being said, (and gain, not security expert here), my understanding is if someone has access to the command line to run any bakery commands (would it be migrate or whatever), does it really matter as it also means it has access to all the source code? Sure, permissions might allow one to execute a file (command) but not read/write it, but…

(Side note, testing could be a pain with improper migration implementation)

I also wonder how general users (you know, the one what are still uses shared hosting kind of users) will have a dedicated ID not allowed to alter table (They’ll use the same ID for both really…). Also note server env should be prioritized over the .env file. In the end, I get the idea, but sure how high of a priority that needs to be, but would be willing to look at a PR or how other framework handle this.

which is stored in a secure manner, and is used for day-to-day running of the application.

I’m curious thought about what the “secure manner” would be?

#3

I see the thread is about the PHP and its DB like Redis. After setting my php redis extension, I eventually dive into this message broker and found many details as per its data types. Talking about thorough security, I found Redis’ data type: String as the data structure, which is similar to Strings in PHP. Redis Strings in Redis are binary safe, meaning they have a known length not determined by any special terminating characters.