We have a security solution that is deployed on premise to companies with big technical infrastructures. We do real time vulnerability/configuration assessment of all critical assets in the network.

The application server (referred to as "our server") has services that usually connect to other assets (like Linux Servers, Network Devices etc) through a Privileged Access Management (PAM) owned by the customer. Once the connection is made relevant data is pulled to our server for further processing and then inserted in the database.

We have some other set of customers who don't have a PAM and we store the private key in our database using AES-256. The respective AES keys are stored on the same server. We can't use something like PBKDF2 or bcrypt to store these passwords because they need to be used to make periodic connections to all assets.

Our server is hardened and continuously monitored by our VAPT team, hence the chances of it being compromised is very less. Worst case scenario, the server get's compromised then it becomes a door to the complete network infrastructure. Which is the primary apprehension of some of our prospective customers. Right now the answer and plan is to revoke key access and remove corresponding public keys from all assets.

Is there a way in which we can store the keys, reuse them and at the same time protect them from anyone (authorised/unauthorised) who has access to our server? We are evaluating some HSM's though we would prefer a solution that does not include extra hardware.

PS: We don't want manual intervention every time our application needs to connect to remote servers. (Inverse) All servers/assets connecting to this central node is also not preferable.

TL DR: How can FileZilla store credentials securely?

1 Answer 1


Your server needs to be able to access the key. Therefore any attacker who is able to execute code on your server can access the key in the same way. Any additional security can only limit the impact on the breach within this constraint.

There is a small benefit to putting the key in a separate processor, and letting the server only make requests to this separate processor (key derivation, signature, decryption depending on what the key is for) and not see the actual bits of the key. Assuming that the separate processor is not breached, this means that an attacker who breaches the server has to keep using the separate processor if they want to keep using the key.

This doesn't prevent the attacker from causing harm, but it means that they need to have a more active and sustained presence. They can't just obtain the key, download it and wipe their traces. This increases the chance that you'll detect the breach. Furthermore, in case of a breach, this is likely to give you a more precise assessment, because you're more likely to have trustworthy logs indicating what the attackers did (and didn't do).

Another advantage is that if you reinstall the server after a breach (still assuming that the separate processor has not been breached), the attacker no longer has access to the old key, so you don't need to rotate it. I don't think this matters in your scenario; it's mostly important for private keys when the corresponding public key has been widely deployed (for example, for a certificate authority, this can make the difference between having to revoke a known list of certificates and essentially going out of business because nobody trusts you anymore).

The separate processor can be a proper hardware security module, but there are cheaper options. A HSM is protected against physical intrusion, and that's a significant part of its cost. Simply putting the key in a separate, dedicated server gives you just as much benefit against network attacks. This can even be a virtual machine, but the attack surface is larger due to the risk of cross-VM side channels and of attacks against the hypervisor. Another low-cost solution is a smartcard, but you get very limited bandwidth.

Note that there is a cost to setting this up: it's only useful if the separate processor never ever reveals the key. The processor may sign data, decrypt tokens, or derive session keys, but it never allows the long-term key to leave it. Not all software support this, but such features may be provided in a generic way by a cryptographic library, for example through external engines in OpenSSL.

If you put the key in a separate processor, don't forget redundancy: you won't be able to recover that key just by restoring a backup.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .