[Feature Request] Allow storing passwords hashed in config files

[ravenclaw900]

Describe the feature request

Currently, the passwords for the admin dashboard and basic authentication are stored in plaintext in the config files. This means that anyone with access to them could get the password. If they were hashed, then even if someone had the password, they wouldn't be able to log in.

Describe alternatives you've considered

Keeping passwords plaintext but only allowing root user to access them, though this could easily be undone.

Affected area

• [x] Docs
• [ ] Installation
• [ ] Performance and Scalability
• [X] Security
• [ ] User Experience
• [ ] Test and Release
• [ ] Developer Infrastructure
• [ ] Client Plugin
• [ ] Server Plugin
• [ ] Extensions
• [ ] Others

[fatedier]

I have a few questions:

1. Which hash algorithm should we used.
2. How to config this feature and keep it compatible.

[ravenclaw900]

1. The PR currently uses bcrypt, because it is a dedicated password hashing algorithm and it is clear that it's a hash (begins with $2y$ or $2a$). It could, however, use SHA512 or a similar algorithm, though it would require a different setting to show that it's a hash.
2. Currently it just reads the first 4 characters of the password, and if it begins with $2y$ or $2a$, it treats it as a hash. This would, however, break any passwords that happen to begin with those. It would probably be better to have a dedicated hash setting to tell if it's a hash or not.

[fatedier]

Can users easily compute the hashed value using bcrypt? Are there any command line tools or other web tools?

I think it's tricky to use $2y$ prefix to detect the algorithm. Can we add new configure like password_hash_algorithm default to none and bcrypt or sha512 or others is optional.

[ravenclaw900]

To compute it you can use the htpassword command from apache-utils, though it's not installed on most systems by default:

htpasswd -bnBC 10 "" password | tr -d ':\n'

I'll add a setting to the config file to tell if it's a hash or not.

[github-actions[bot]]

Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

[ravenclaw900]

bump

[fatedier]

When we switch our configuration file to yaml or json, we can use more structured configuration to describe this functionality.

Example:

httpUser: abc
httpPassword:
  value: abcd
  hashAlgorithm: sha512