5

Suppose we are in the field of desktop applications which need to store their data in a database. How do I store the password for this database avoiding the most obvious mistakes, which are:

1) hard coding the database password inside the code (cited as #21 coding horror under „Hard-coded passwords“ inside http://www.codinghorror.com/blog/2009/01/top-25-most-dangerous-programming-mistakes.html)

2) encrypting the password of the database and storing it in a file, you would shift the problem to: „where do I store the password which encrypts the database's password?“

3) using a remote database server and an n-tier architecture where the program doesn't directly access the database but authenticates with another layer which grants each operation and forwards it to the database layer. Everything is encrypted through ssl and authentication is done via a digital certificate (so effectively using public key cryptography).

Number 3 is actually a solution but it doesn't apply to desktop applications which need to work offline!

Someone on another similar question answered that to „give untrusted users trusted access to a system“ is unfeasible that's why DRM never worked, however he didn't cite a proved study or a proved theorem.

Notice the same problem happens if we want to encrypt the database: where do I store the password with which I encrypt a database in a desktop application?

Can anybody shed some insight? Thank you

NOTE: this same problem is discussed in CWE-259: Use of Hard-coded Password but no definitive solution is explained

Improve this question
2
  • Not an answer to your whole question but to this: "Someone on another similar question answered that to 'give untrusted users trusted access to a system' is unfeasible that's why DRM never worked, however he didn't cite a proved study or a proved theorem." The answer is that it's not theory, it's practical, and it doesn't need to be studied, because it's widespread, particularly in the entertainment and gaming industries. The most well-known example is that of DeCSS, the encryption system that was supposed to protect DVDs.
    – Xander
    Commented May 2, 2013 at 15:23
  • I'm aware of that, I'm just not completely certain whether my question above can be reduced to the likely more difficult task of safeguarding a digital good from being exchanged or decrypted.
    – dendini
    Commented May 2, 2013 at 15:45

4 Answers 4

Reset to default
5

Any secret key that you embed in a program can be recovered by a person who has full access to that program, the best you can do is make it time consuming to do so.

But let's say you could make the secret totally unrecoverable by analysing the binary.

The user could perform dynamic analysis by running the program while monitoring it's memory and wait for the key to be constructed.

OK let's say you have managed to use a key without ever building it completely in memory somehow.

The key still has to be used for something, and the user could examine that mechanism and use the anti-forensic key in the same way.

Let's say the mechanism for constructing and using the key is totally obfuscated beyond recovery.

The key still has to depart your program in order to be useful outside it. I could just masquerade as a database waiting for my secret key to be passed to me, I wouldn't have to analyse your program at all. Any form of encryption you use would have to be readable by my database software, which I am also in complete control of regarding keypairs and such.

But I have written my own database format which is loaded into the same program as the key which you can't read.

So your program is completely locked down and everything happens inside. Except it doesn't - you will load dynamic libraries which I could edit thereby changing the behavior of your program.

Ultimately there is nothing that runs on my machine that I do not have final control over. This is not something you can avoid.

Improve this answer
2
  • Some points I don't agree with 1."The key still has to depart your program in order to be useful outside it.", not if I use public cryptography. 2."you will load dynamic libraries which I could edit thereby changing the behavior of your program." I can compile everything statically and not use any external library
    – dendini
    Commented May 3, 2013 at 8:16
  • 2
    1. public key crypto still requires decrypting... 2. I can edit your program just as easily. The point of my answer was to illustrate that wherever you turn, it is quite easy for a user to head you off. You cannot have more control over a user's machine than the user.
    – lynks
    Commented May 3, 2013 at 9:29
1

You can't. It's a chicken or egg problem.

Have the user of the application enter the password every time the database is used.

Improve this answer
3
  • The user must not know the password and must not be able to access the database directly, but must be able to use the database through the software. I like the chicken and egg reference but it doesn't really fit my situation or at least it must be proved. It sound however a lot like a rephrasing of the impossibility to „give untrusted users trusted access to a system“.
    – dendini
    Commented May 2, 2013 at 15:02
  • 1
    @dendini Your scenario IS a chicken or egg problem. Hardcoding the password into the application binary is not an option. Simple reverse engineering will reveal the password, even if you try to obfuscate it. Storing it somewhere on the filesystem is not an option either, any attacker with access to the computer can simply pull the password from the system. And obviously storing it in the database is not an option....
    – user10211
    Commented May 2, 2013 at 15:11
  • Also communicating securely over a public channel without having to agree upon a shared key beforehand seems a chicken and egg problem to me, however we know public key cryptography makes it possible. My point is you might be right but it's strange to me there's no theorem or well known paper on the subject.
    – dendini
    Commented May 2, 2013 at 15:18
1

You state that the following doesn't apply because desktop applications need to work offline:

Using a remote database server and an n-tier architecture where the program doesn't directly access the database but authenticates with another layer which grants each operation and forwards it to the database layer. Everything is encrypted through SSL and authentication is done via a digital certificate (so effectively using public key cryptography).

If your application needs to work offline and can work offline, then one of these is true:

  • The database is stored locally, in which case a password is unnecessary, as the user only has access to their own data. An example of this would be backing your application with an SQLite database.
  • The database is stored remotely, but the ability to connect to it is optional. If this is the case, then you can go through proper authentication when the application is no longer being run offline.
Improve this answer
1
  • This desktop application has a client server architecture inside its LAN, so many instances of the program share a database which is opened as a service by one instance elected as the server. This whole architecture doesn't have to contact the external internet and the whole database has to stay within premises.
    – dendini
    Commented May 3, 2013 at 8:13
0

For a desktop application I would prefer password hashing with salt. Hashing with SHA-256 or SHA-1 plus salt seems good. Because Ideally an encryption key for a standalone system as explained above can be obtained by some malicious trick. hashing is a one way street salt ensure some strength, so it isn't so bad

Improve this answer
1
  • 3
    how do you pass the hash to the target application?
    – schroeder ♦
    Commented Jul 5, 2016 at 17:33

You must log in to answer this question.

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