Describe the bug
Fluent Reader (and also thus Fluentflame Reader), does not encrypt its tokens or passwords
at rest locally. This, I would consider, is bad. I don't think we should make it trivially easy for a malicious program to scrape up passwords and tokens blindly. AES256 should be fine, and it should be handled as much as possible on the main process side.
Also wondering if we should allow exports of the tokens/passwords at all? If we do encrypt them, and then if we change the process in which they are encrypted, these will be invalidated anyways.
Unfortunately, many services (like FeederAPI) MUST send a static password in the body directly, so we can't even use short-lived generated API tokens or anything like that.
To also be clear, having these passwords is not super useful, to my understanding as an attacker unless there's an exploit on the API side. The APIs that say, the FeverAPI, exposes to credentialed users is pretty minimal.
To Reproduce
Add a service (e.g. FeederAPI)
Expected behaviour
Don't store passwords directly in the config file in plaintext? Double check that the config
file has appropriate permissions at least? Maybe see how browsers handle
local-only credentials?
Platform (please complete the following information):
- OS: Primarily a Linux issue as the
config.json is not guaranteed to be rw- --- ---, when it should be treated similarly to a private SSH key.
- Version: All
- Package Type: All
Describe the bug
Fluent Reader (and also thus Fluentflame Reader), does not encrypt its tokens or passwords
at rest locally. This, I would consider, is bad. I don't think we should make it trivially easy for a malicious program to scrape up passwords and tokens blindly. AES256 should be fine, and it should be handled as much as possible on the main process side.
Also wondering if we should allow exports of the tokens/passwords at all? If we do encrypt them, and then if we change the process in which they are encrypted, these will be invalidated anyways.
Unfortunately, many services (like FeederAPI) MUST send a static password in the body directly, so we can't even use short-lived generated API tokens or anything like that.
To also be clear, having these passwords is not super useful, to my understanding as an attacker unless there's an exploit on the API side. The APIs that say, the FeverAPI, exposes to credentialed users is pretty minimal.
To Reproduce
Add a service (e.g. FeederAPI)
Expected behaviour
Don't store passwords directly in the config file in plaintext? Double check that the config
file has appropriate permissions at least? Maybe see how browsers handle
local-only credentials?
Platform (please complete the following information):
config.jsonis not guaranteed to berw- --- ---, when it should be treated similarly to a private SSH key.