Encryption - Storing the salt in compiled vb.net code....safe ?

Simple question....I can't seem to find a credible answer to.

I've created a client server program that uses md5 + 3des encryption.  I have stored a salt in the code, which gets concatenated onto the original key before hashing, then the message is encrypted using the hash of the salt + key + salt.

My question is.... how safe is the salt ?  After compiling this into an executeable....would someone be able to "decompile" it and find out what the salt is ?

My guess is no.... otherwise no encryption would ever be truly secure.  Knowing the salt or being able to fully decompile the code would allow someone to create a hash database and make any app insecure.

The app is very security sensitive.  It has to be as close to 100% secure as possible.

Does anyone have any credible input on this ?  How safe is the compiled code, and are there code obfuscation methods I should be employing ?
LVL 25
Ron MalmsteadInformation Services ManagerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

JonasMalmstenCommented:
The compiled code is not very secure. Any descent hacker with access to the executable and willing to spend enough time will be able to figure it out. The trick is not to decompile it, they can never get your original source code back. What they do is run it through a debugger like for example SoftIce.
http://en.wikipedia.org/wiki/SoftICE
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jaime OlivaresSoftware ArchitectCommented:
the salt shouldn't be fixed but random. The random seed should be based in timer or other technique.
The strenght of a cypher algorithm is not increased by hidding it. Modern algorithms are intrinsecally secure because of the cyphering technique itself, and the number of bits, which demands a long period of time (centuries) to be cracked by brute-force techniques.
About 3DES, it is not so secure nowadays. You should use at least 256-bit schemes, like AES (Rijndael).
0
Ron MalmsteadInformation Services ManagerAuthor Commented:
....ok, I kind of get what you are saying.  But since they can't get the original source code, how would they get the string ?

Let's say the string looks like this...   Ci-LIL@dk10v23nj-q9vin#KQJ#Lbvj-0893m=
Would the actually be able to figure that out ?
0
Become a Certified Penetration Testing Engineer

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

Jaime OlivaresSoftware ArchitectCommented:
please explain where the key come from...
Salt is used to secure the message, not the key. Unless the key is wrapped by another key, like in PGP.
0
Ron MalmsteadInformation Services ManagerAuthor Commented:
How could it be random and still work on both ends of the client server app ?
Or do you mean ..it should change programatically ?
0
Ron MalmsteadInformation Services ManagerAuthor Commented:
jaime_olivares: the salt is basically... "made up"... I made it up.  It exists in both the client and server apps.  Using the client and server, the user provides the key, which in the code is concatenated with the salt.  That combination is Hashed Md5 and is the actual key used in the 3des algorithm.

My question is...   is there a way someone could find out what i've chosen for a salt ?
0
JonasMalmstenCommented:
Yes, it doesn't matter what the string looks like. They can for example start your program with a key they provide. Since they know what the key looks like they can locate it in the computers memory (a low level debugger has full access to all system memory). Then place a break point that will stop program execution every time that mamory location is being accessed. Once you concatenate it with the salt, they have it.

If you are using an external library to compute md5 or 3des it may be even easier. Simply place a breakpoint at the entrypoint to this library and watch what parameters are sent in.

About the salt. If you are using it to prevent a ready made dictionary attack it may be better to randomize a new salt for every session or with regular intervals and send it in clear text to the server. Every time you change the salt an attacker will need to construct a new dictionary which is very time consuming. Or why not use XOR on this salt with the one you have build into your executable, now they must both generate new dictionaries and crack your executable :)

Then again, the hardest part about security may not be the encryption, but the authentication and protocol used to relay the data. Why not use something already existing like SSL or tunneling all traffic through SSH?
0
Jaime OlivaresSoftware ArchitectCommented:
Why not use something already existing like SSL or tunneling all traffic through SSH?
agree. you don't have to reinvent the wheel. this is a common security scenario.
0
Ron MalmsteadInformation Services ManagerAuthor Commented:
JonasMalmsten / Jaime

Really there is not communication for the server to client.... it's simply messages that are encrypted to cyphertext before being sent over a tcp or udp socket connection to the server.  There's really nothing to "hack" into, except a sniffer would be able to pickup the ciphertext.  I just wanted to make sure that nobody would be able to decode it on their own....EVEN IF they knew what the key was...because they wouldn't know the salt or where and in what fashion it was added to the original key.

So basically you guys are both saying.... that a compiled executeable, someone would be able to find out >>>  dim strsalt as string = "foo" & strkey & "bar"   They can't see the actual line of code, but they can get the string value somehow using kernel debuggers........ right ?
0
Ron MalmsteadInformation Services ManagerAuthor Commented:
Jonas.... are you from Sweden ? ,and is Malmsten your actual last name ?
I know this is "off topic"... but we seem to have a similar last name.  I've never met anyone with such a simliar last name as me.... so I just have to ask.

My last name is Malmstead..., and my ancestors are from Sweden...


How small of a world would it be, if we shared common ancestors ?
0
JonasMalmstenCommented:
It is possible :), but my name is quite common in Sweden.
0
Ron MalmsteadInformation Services ManagerAuthor Commented:
Cool....

It's not common at all in the US...which is why I asked.
0
Jaime OlivaresSoftware ArchitectCommented:
>>"foo" & strkey & "bar"
What I am trying to say is that "foo" and "bar" can be random. This will increase complexity to any potential cracker. Once you decode it, just you take the string portion after the 3rd character up to the last minus 3 characters. Every cyphered message will be totally different because of the random salt.
0
Ron MalmsteadInformation Services ManagerAuthor Commented:
oh..... ok ... I think I get it now...

I should A) use the salt with the message, not the key, then strip it off after decoding....and B) the salt should change programatically somehow...as long as it will always match on both ends (client/server)

Thanks.
0
Ron MalmsteadInformation Services ManagerAuthor Commented:
Thanks.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic.NET

From novice to tech pro — start learning today.