I have realized some time ago that we should not put the login/password for accessing a remote database server directly into a executable file because of the reverse engineering and memory decoding. I do not know if this is what everybody already do, but I prefer to first access some encrypted API with a key or phrase and then receive the login and password (also encrypted) to start accessing the database.

What I do not know is of a good encryption system that can be decryption with the right key or phrase that we use to encrypt the data at first time.

So what I am asking is if it exists and where can I see the solution for working with systems that uses Delphi, PHP, Java and JavaScript? Because there are these different parts of the system that may communicate with that kind of encryption.

I am not talking about something like SHA/MD5, that can't be recovered.

  • 2
    You probably want to provide an API for accessing the database, with your executable calling the API. Alternatively, you can let PUBLIC connect to your database, but only grant it necessary permissions (select and insert on specific tables, for instance); if that's not granular enough (and it probably isn't), you can provide an API by way of stored procedures that implement the necessary business logic.
    – Matt
    Apr 5, 2013 at 18:09
  • SHA/MD5 are hash algorithms and irreversible by design. They are not used for encryption but combined with encryption algorithms make elegant security solutions i.g. digital signature, public-key cryptography...
    – Xaqron
    Apr 5, 2013 at 19:25

1 Answer 1


If you're putting a binary on an untrusted computer, and that binary needs to access sensitive information like database passwords, there is literally nothing you can do to ensure the privacy of that information. You can slow attackers down, but if an attacker could do significant damage with those database credentials, your architecture is fundamentally flawed.

For instance, the best you can probably do is to use something like AES-128-GCM to encrypt the credentials. But you also have to disguise the key: typically, this means obfuscating it by "generating" the key through a deterministic process like performing some computations, XORing the result against some fixed data, and appending and shuffling that with the results of other computations.

But now you still have problems. The key itself will be in memory, and once decrypted, so will the database password. And you really can't stop a user from viewing the contents of their own computer's memory.

Again: you can make the problem harder, but if your architecture requires putting incredibly sensitive information like database passwords onto untrusted computers, you are already screwed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.