[raverbashing]

- Keep passwords in memory (so as if you start the service it prompts for the password)

- Asymmetrical crypto. So for example, you encrypt your CC data upon sign-up but then to run the charges you need the private key (and this is somewhere else)

- Enable SSL communication with your DB. Postgres has this, because being defeated by network sniffing is bad.

[ra]

Memory is not secure. It's quite a common attack to grab keys / passwords from the memory of an executing program.

[raverbashing]

No, it is one of the safest places.

If your attacker has access to arbitrary memory of a process, you're using an insecure OS/version. Or they dumped your process memory using a vulnerability (in your system)

Yes, there are some possible attacks (page file, cache, etc)

Attacking memory after a reboot requires physical access (unless you hibernated without an encrypted file, in this case...)

It certainly beats the security of file/network

[ra]

Just because it's more secure than network / file doesn't mean it's secure. That's why we have smartcards / HSMs.

[raverbashing]

Smartcards are vulnerable as well and there has been successful attacks towards some smartcards (google it)

And not every system has an HSM available

[ra]

Sure but smartcards and HSMs are slow and in a properly managed environment are much safer than memory.

Whether or not the OP has an HSM is moot. The OP said, "I want to design and implement a solution as secure as it can be" ... and that means (among many other things) keys on HSM.

[nandemo]

In the first case, what if we're running a service in a cluster that starts instances automatically?