Request: Stronger initial login credentials

[jayaddison]

As it becomes easier to use and deploy grocy, it makes sense to improve the security of the default login credentials.

There's a tricky balance here; we want to reduce the possibility for unauthorized access to a grocy instance, while allowing users to restore access to the application and data if they forget their password in future.

It may be reasonable to assume that a person running grocy on a home device would be able to access the device and/or filesystem for truly urgent for recovery purposes.

Logging into the device and/or accessing the filesystem directly might also be able to provide 'in-person-only' reset workflows.

A suggested new-instance setup phase would involve:

• Begin with a limited user dialog that only listens on limited network interfaces/ports (todo: how?)
• Prompt for a password via the dialog, and ensure that it is a strong password -- or generate a strong password for the user if they prefer
• Start the full application

There are a lot of possible tradeoffs and design options here; we might be able to discover how other projects achieve this and get some ideas from them (linuxserver, for example?).

[berrnd]

Begin with a limited user dialog that only listens on limited network interfaces/ports (todo: how?)

grocy is a PHP app, not a webserver - so this is technically completely out of control of grocy.

 

Prompt for a password via the dialog, and ensure that it is a strong password -- or generate a strong password for the user if they prefer

If we do that, and grocy is set up to be reachable from the public internet, everyone could (yes, theoretically, most probably not really a problem in reality) catch up there and create those initial credentials.

 
grocy is generally based around GIGO, so if the user doesn't care or whatever and leaves the (clearly mentioned to be changed) initial credentials + makes their instance available publicly on the internet (since weak credentials are commonly not a problem in your home network) or maybe even disables authentication at all (config option ref) - that's all someones choice.

[jayaddison]

grocy is a PHP app, not a webserver - so this is technically completely out of control of grocy.

If we do that, and grocy is set up to be reachable from the public internet, everyone could (yes, theoretically, most probably not really a problem in reality) catch up there and create those initial credentials.

Yep, agreed for both of those 👍

Could you transfer this to grocy-docker? I'll do some research soon; it seems like this should be a well-known problem with existing and reusable solutions (?).

[jayaddison]

grocy/docs#7 could make sense to also transfer to grocy-docker, with this plan.

[jayaddison]

I wonder whether the running container ID (not the image ID) could be introspected and used as the default admin password. There could be a question about whether the user wants to update that on first-login -- but it'd be fine to choose not to.

That wouldn't be perfect, but the container ID is information that random systems and/or people scanning the network for known applications shouldn't be able to obtain (unless they have some login access to the host machine already), and that a person should hopefully be able to access easily during first-time Grocy container startup (todo: check -- is that true?).

[zommuter]

Another option could be storing an initial password (or better the hash thereof) in grocy.env, but implementing that would still require some effort I guess.