[FR] Don't read plain passwords as an environment variable

[pluiedev]

What

Fusion currently gets its password directly from the PASSWORD environment variable, which is inconvenient when running it under a hardened systemd service (which expects programs to use paths to passwords to ensure security), and downright dangerous as a stack overflow exploit can easily read through all environment variables even in other processes.

Why

Fusion only using plain passwords (not hashed or salted or peppered) in anyway troubles me and prevents me from recommending Fusion to other people, who are much more privacy and security-aware than I am, and even I think that this is a security hole if one is unaware.

(Optional) How

Allow passwords to be read from protected paths, add hashing/salting/peppering/etc.

[0x2E]

Hey, thanks for the report. Will add a new env like PASSWORD_HASH.

[mtlynch]

Fusion currently gets its password directly from the PASSWORD environment variable, which is inconvenient when running it under a hardened systemd service (which expects programs to use paths to passwords to ensure security),

Can you provide a link with more information about why hardened systemd services should read secrets from a file? I'm not familiar with that guidance.

and downright dangerous as a stack overflow exploit can easily read through all environment variables even in other processes.

If a stack overflow exploit gains remote code execution, it's game over anyway. If a malicious process can read fusion's process memory, they can read the plaintext password as it arrives from the client as well as all of the server's session tokens, and all the data the server is protecting behind a password.

It's a bit more of a concern if there's a leak of process memory through a vulnerability similar to Heartbleed. In that case, it's more negative if the attacker manages to dump the password from server memory. But again, they're about as likely to do that as they are to leak the session token except that the session token is longer.

Fusion only using plain passwords (not hashed or salted or peppered) in anyway troubles me and prevents me from recommending Fusion to other people, who are much more privacy and security-aware than I am, and even I think that this is a security hole if one is unaware.

I don't think this is a credible argument for salting/peppering.

In general, it is a good idea to salt/pepper your password hashes, but that assumes a different type of app and threat model from Fusion's.

Fusion's security model assumes that a single user is the sole owner and admin of the app. There's no password hash, so there's nothing to salt.

Generally, salting/peppering is useful when you're storing passwords for many users. If there's no salting/peppering, then an attacker can try hashing a password and checking for any matches in the database. There are also pre-existing rainbow tables for different hashing schemes. Giving each hash a unique salt/pepper prevents the attacker from reusing compute across the whole dataset and forces them to brute force each hash separately.

Fusion could add an option to let the user specify a hash rather than a plaintext password, but I think that's a lot more work/complexity for not much value. If the attacker is able to steal the app's root password hash, they've probably completely compromised the app anyway, so they can get the plaintext password from there (e.g., force invalidate all sessions and steal the plaintext password next time a client authenticates).