firefly-iii-fints-importer icon indicating copy to clipboard operation
firefly-iii-fints-importer copied to clipboard

Enable encrypted password storage

Open TyrionWarMage opened this issue 1 year ago • 2 comments

I was not comfortable with storing my password in plaintext on any server. Therefore, i created an encryption feature.

DISCLAIMER: I'm not an IT security expert and just implemented it using a guide. Severe security vulnerabilities are likely.

Requires the sodium extension to be enabled (php core component)

It works as follows:

  • Call index.php?generate to get into the generation frontend.
  • Add results to the config file and store the secret key
  • Call index.php?key=KEY for decrpytion

Considering my PHP knowledge is based on stack overflow and copy/paste, i assume quite a few "suboptimal" code pieces 😄

TyrionWarMage avatar Oct 27 '23 20:10 TyrionWarMage

Hi, I fully understand your hesitation to store a password as plaintext. However, I don't think your suggested solution is the best way to approach this problem, mainly because it adds a lot of complexity. In your solution, one sends a key to the importer so that it can decrypt the bank password. Wouldn't it be easier to add a functionality where one directly sends the bank password instead? In fact, if you are using the web frontend rather than the headless mode, this is roughly what happens already: If you leave out only the bank password in the config json, you will be asked to enter only this missing piece of information.

A similar approach for the headless mode is still missing, but probably only requires few code changes.

What do you think? :)

PS If you are really concerned about security, please also note that, depending on your setup, the above method might not prevent your bank password from being stored on disc in plaintext: #118

bnw avatar Oct 28 '23 22:10 bnw

Hi,

the feature is intended for the headless mode. My way of thinking: For fully automated execution, you can not prevent storing the "full" secret (password) somewhere. - Either on callee (server) or caller (client/cron job) side. Therefore, the best one can probably do is to prevent plaintext storage on both sides, by splitting the secret into two parts. - And that is what i did. - In fully automated mode, i think the added complexity doesnt matter much, but i wanted to keep it manual-compatible. Meaning, you can still use the same configuration by either sending the key or by manually entering the password.

I'm aware that callee and caller will usually be the same machine, but i still think this way makes it much harder to obtain the password.

PS I was not aware the session store is a disk file, i was assuming it is memory stored. However, this seems like a general issue, not just concerning this PR?

TyrionWarMage avatar Oct 29 '23 08:10 TyrionWarMage