saving passwords inside your application code

Question

Hello all,

I have a doubt concerning how to store a password for usage in my application. I need to encrypt/decrypt data on the fly, so the password will need to be somewhere. Options would be to have it hard-coded in my app or load it from a file.

I want to encrypt a license file for an application and one of the security steps involves the app being able to decrypt the license (other steps follow after). The password is never know to the user and only to me as e really doesn't need it!

What I am concerned is with hackers going through my code and retrieving the password that I have stored there and use it to hack the license breaking the first security barrier.

At this point I am not considering code obfuscation (eventually I will), so this is an issue.

I know that any solution that stores passwords is a security hazard but there's no way around it!

I considered assembling the password from multiple pieces before really needing it, but at some point the password is complete so a debugger and a well place breakpoint is all that is needed.

What approaches do you guys(and galls), use when you need to store your passwords hard-coded in your app?

Cheers

Answer 1

Decide now how much time/effort you want to spend on preventing piracy. If someone is determined, they're probably going to get your application to work anyway.

Answer 2

I know you don't want to hear it, but it's a waste of time, and if your app needs a hardcoded password then that is a flaw.

Answer 3

I don't know that there is any approach to solving this problem that would deter a hacker in any meaningful way. Keeping the secret a secret is one of cryptography's great problems.

Answer 4

My personal opinion is the same as GregS above: it is a waste of time. The application will be pirated, no matter how much you try to prevent it. However...

Your best bet is to cut down on casual-piracy.

Consider that you have two classes of users. The normal user and the pirate. The pirate will go to great lengths to crack your application. The normal user just wants to use your application to get something done. You can't do anything about the pirate.

A normal user isn't going to know anything about cracking code ("uh...what's a hex editor?"). If it is easier for this type of person to buy the application than it is to pirate it, then they are more likely to buy it.

It looks like the solutions you have already considered will be effective against the normal user. And that's about all that you can do.

Answer 5

I know that I can't stop a determine hacker, but I don't want to make life easy for any aspiring hacker that likes to crack software during lunch break!

What I would like to know is what options are usually taken in this regard.

If I need to encrypt anything "in situ" I need for the password to be "in situ" as well.

My question is how can I protect the password itself in the code - let me rephrase that - how can I give it some measure of protection.

In this respect I have two contrary restrictions.

• I don't want to ship a global password with every release because if any hacker hacked one, he/she would be able to hack all version.

• On the other hand I don't want to generate a unique password at install time because I would still need to store it somwhow and... we would be at the same place.

Ideas? Suggestions?

Answer 6

An approach I have done in the past was to generate an unique ID during the install, it would get the HDD and MCU's SN and use it in a complex structure, then the user will send this number for our automated system and we reply back with another block of that, the app will now decrypt and compare this data on the fly during the use.

Yes I works but it still have the harded password, we have some layers for protection (ie. there are some techniques that prevents a mid-level hacker to understand our security system).

I would just recommend you to do a very complex system and try to hack it on your own, see if disassembly can lead to an easy path. Add some random calls to random subroutines, make it very alleatory, try to fake the use of registry keys and global variables, turn the hacker life in a hell so he will eventually give up.