Encrypted api fields in config.json about freqtrade

[stash86]

It's just a PR away. We will be happy to review your PR

[xmatthias]

to be quite honest - i think this would leave you in a false sense of security.
If your server is breached, you're screwed anyway.

Keys are still in memory of the process (they need to be) - and can hence be extracted pretty easily by anyone knowing even remotely what they do.

As an aside - you can already use environment variables - so nothing really prevents you from doing something around the following (inline environmental key assignment).
FREQTRADE__EXCHANGE__KEY=$(echo "APIKEY" | openssl enc -aes-256-cbc -a) freqtrade trade

---

You'll however quickly notice the "operational" difficulties in this.
Assume your bot is in a (high risk) trade - and for some reason, it restarts (maybe your provider restarted the VM due to a hardware error). You're stuck "someplace" - and the bot can't restart because it's missing the keys ...

[eltech35]

Thanks for the rapid answer, got it.
I popped the question cause another bot i'm using (hummingbot) encrypts the api passwords for this reason and it makes sense to me.... will look into if it's just cosmetic now.

[xmatthias]

Well every bot will work the same - the key MUST be in memory in cleartext to attach it to the requests to the exchange- and it'll be (roughly) the same spot for every instance of that bot.

It essentially boils down to the risk profile you're trying to optimize against.
If you assume an attacker can read your disk - it's almost guaranteed that this attacker can also execute programs on your server as he has to be "on" that server somehow - which essentially means that attacker is very likely to be able to read the memory of running processes (and maybe even intercept web requests).

That's clearly a risk profile freqtrade does not address.
Running in a non-secure server (where attackers can read your disk / memory) is clearly not a recommended (nor supported) mode of operadi - as in that case, even an IP lock on the API key will not help you - that attacker can simply use your key from your server ...

I don't necessarily see this as problem - protecting from this scenario is near impossible if you think about it

[moinonin]

the solution to this issue may be to run freqtrade in a kubernetes cluster and make sure to use kubernetes secrets

[xmatthias]

no, k8s is not the solution to this.
the freqtrade process / container will still have the secrets (it must have the secrets) - so it's just adding another complication layer for no good reason.

[eltech35]

Looking into screen/tmux freqtrade and vlocking the session so even someone getting access to the the host can't access the ENV inside the screen/tmux session....
Could perhaps work. I already run freqtrade thru screen sessions.

[xmatthias]

even someone getting access to the the host can't access the ENV inside the screen/tmux session

Please look into what a memory dump is :)

you can lock the session so no one can log into your shell - but it can still see what's in memory of every process running.

[moinonin]

I see. Unless if it is presented in the config as encrypted. Then decrypted in the exchange.py like this:

ex_config = {
    'apiKey': decrypt(exchange_config.get('key')), # using some complicated encryption and decryption routine :dagger: 
    'secret': decrypt(exchange_config.get('secret')),
    'password': exchange_config.get('password'),
    'uid': exchange_config.get('uid', ''),
}

[eltech35]

don't want to bother your time @xmatthias ... just ideas, if i found something pertinent / bullet proof, i will report it here.

[xmatthias]

@moinonin nope - it's in a variable - it's visible in memory.
even if we were to keep it encrypted down to ccxt - it'd still be in memory within ccxt - so a memory dump can read it just as easily.

This is not a scenario we're going to be able to support.
Once an attacher is on your host - there's no way i can see that freqtrade can still protect your keys (that attacker could just as easily sniff the keys required from the network of your server).

Simply put - please make sure to keep your server protected.

That's usually simple steps, like disabling password authentication for SSH,making sure no vulnerable services run on the server, ...

[eltech35]

Only for intellectual purpose, not sure to implement it, but i found a "way":
Use PortKnocking (usually used to open/close SSH port with a sequence of TCP/UDP ports), i made a 1000 lines 8 ports sequence list (each line is unique). You can use each 8 ports sequence only 1 time.
If the 8 ports sequence is knocked in the last minute, you can login to SSH (with key auth), regular .bashrc file, if not (assuming someone succeed to get your auth key), the .bashrc in user profile contains a link to a nuke.sh script that will:

• secure delete keys.json file containing CEX API Key/secret
• killall -9 every freqtrade instance
• unset ENV variables used by freqtrade or CCXT to store API key and secret
• drop a telegram ALERT to server owner indicating server and SSH keys are compromised and all freqtrade instances have been dropped, dispose manually of ongoing CEX orders.
• reboot server
  This way, no need to encrypt/decrypt API details.

Already using portknocking this way to connect my production servers (for the last 5 years at least), better nuking the VM (incremental backups every 1h) rather than being at risk of loosing capital.
Also, SFTP is disabled on server, so you can't alter the .bashrc file before login.

Again, this is intellectual purpose.... for security paranoids only.

Out of this, making me think... perhaps a "secure your server/VM running freqtrade" minimal guide would be a plus in freqtrade manual ?
Just the minimal, secure your SSH, don't expose your FREQUI port, remind api details are in clear text and user's responsability to keep them secret.

[xmatthias]

Out of this, making me think... perhaps a "secure your server/VM running freqtrade" minimal guide would be a plus in freqtrade manual ?

absolutely - more than happy to get a PR improving docs :).
Now how precise / in detail this should go is a different question.

What you talk above sounds great - but having all of this as part of the freqtrade docs also means that we'll need to try and support users in this if they encounter problems - which i'm not sure is possible - (aside from being overkill).

You can also jeopardize all of the above by exposing an old version of "application X" - which might not be related to freqtrade - but is still something that's "Open" and provides a way in - which is however something that should be mentioned.