0

How to store sensitive information like licences (for 3rd party components) or file decryption keys on client side computer?

At the moment this kind of information is written to settings file, what is included to dll. But if you decompile the dll, then you can find out the values.

The application is built in WPF and is mostly offline.

RassK
  • 515
  • 6
  • 20
  • 1
    Related (or _horizontal_ duplicate): [Where can I store (and manage?) Application license information?](http://stackoverflow.com/a/20676247/1207195). It's about your own license but same technique can be applied for any other sensible data. – Adriano Repetti Oct 28 '14 at 12:27
  • The applications own licence is safe, because its signed on server side. But some keys and licenses for other parts are just clear strings. Like im using a 3rd party control, which requires licence, and its stored inside a dll. If you decompile the dll, then you can steal the licence what our company owns. – RassK Oct 28 '14 at 12:30
  • Then IMO you should _hide_ them (see linked post for various ideas). Perfect would be to never ever materialize them (in plain) on disk but it's not always possible. What to use depends on features and freedom you have with them (can you pass them a Stream instead of path?). If problem is their license then...well it's THEIR problem, not your. If you want to do something then you may hide (little bit) their own DLLs (again see linked post). – Adriano Repetti Oct 28 '14 at 12:32
  • I think the only way is to protect it is with a key that is not stored on disk... pretty much what a password is. – J.H. Oct 28 '14 at 13:13

2 Answers2

0

If it's on the client side, it's impossible to ever be 100% secure without server verification: you can't encrypt a decryption key, you have to leave it in plaintext somewhere.

At the same time it's normally sufficient to just add a verification to the licence - eg the certificate has a line which is the hash of the certificate, plus a salt hardcoded in your application. If the user tries to edit their licence, the hash will change and you can throw an error.

With decryption keys, you should look at public/private key pairs, but as above, you can't encrypt the decryption key (at least, not without storing another unencrypted key)

Jon Story
  • 2,881
  • 2
  • 25
  • 41
  • Exactly. Like in my case, i still need to store a plain key. I have a lot of projects for supporting core. Each one of these could store a part of the key and in some point one dll could makes sure, that the full key is constructed in right way. Seems a great option with obfuscating. – RassK Oct 28 '14 at 12:50
  • Obfuscating will only deter the most casual attacker - anyone with the intent and ability to go playing around in your code will probably have the patience and ability to de-obfuscate your keys etc. And if they can reverse engineer one DLL, they can reverse engineer the de-obfuscation code too... – Jon Story Oct 28 '14 at 13:11
0

Every dll can be decompiled that is just a fact. The only thing you can do is to use things as code obfuscation and add the keys to your dll in way they are hard to ready. Make the 'criminal energy' required to read the hidden stuff reasonably high.

As for your case: better not store the license in a file that is embedded in the DLL (super easy to read) but maybe put it directly into your code and use code obfuscation. That way it will be very hard to read this third party license.

Sjoerd222888
  • 3,228
  • 3
  • 31
  • 64