mirror of
https://github.com/fosrl/pangolin.git
synced 2026-03-12 01:44:06 -05:00
Admin passwd in cleartext in configuration file #194
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @M3rcur-x on GitHub (Mar 30, 2025).
Hi,
I just setup Pangolin on my VPS and the password of my admin user is available in cleartext in the configuration file of Pangolin (config/config.yml, users -> server_admin).
Why it isn't hashed ? While this account is also stored hashed in DB.
@miloschwartz commented on GitHub (Mar 30, 2025):
The admin password is hashed before being entered into the database. You can set the password with an environment variable if you'd prefer
USERS_SERVERADMIN_PASSWORD. This would let you pull from a secrets manager store.@M3rcur-x commented on GitHub (Mar 30, 2025):
I agree but there is no reason to store it in cleartext in this file after using Pangolin installer.
@miloschwartz commented on GitHub (Mar 30, 2025):
Every time the server starts it copies the password into the database which lets the server admin rotate the password so they don't get locked out.
@M3rcur-x commented on GitHub (Mar 30, 2025):
This field should be empty by default. The server can check and rotate this password (then delete it) if set after each start.
I understand the purpose of this field but this is a security issue to store a password like this. (even if it readable only by root)
@tomasodehnal commented on GitHub (Apr 5, 2025):
I would like to argue in favor of starting Pangolin without password being present in clear-text in configuration or environment variable. If I would like to save myself from starting Pangolin manually, I would need to store the password on disk anyway, which I believe we should prevent.
I understood that the reason for requiring the password is a safeguard to prevent locking out of the administrator. I agree with @M3rcur-x - having the password (or even whole
userssection) optional would still allow me to override it via config or env var when needed. In normal circumstances only the hashed version would exist in the database.