I have a project where you must log into a webservice from the client. The client app is not being built by me. In order to log into this web service, the app programmer needs to enter a username and password, note, the app user will not know these credentials. I need a better method of doing this as i'm unsure as to how safe storing the username and password in the exe are. Do you think a) storing them encripted in an external file would help, b) dotfuscate c) encripted in a recourse d) an idea from you... Thank you

You can't trust the client. Even if you encrypt the password in the EXE, you have to decrypt it to send it to the server. If you're trying to prevent somebody from running 'strings' on the exe to figure the password out, then just XOR the password with some random bits and you're set. Don't put a lot of effort into encrypting the password because to do this you'll be putting the key and the algorithm into the EXE too. Any competent hacker will crack that in no time.

Also worth noting that if you're connecting to a resource over the network that's not an encrypted stream, then just hooking up a password sniffer will quickly reveal the password.

Anyway once you decrypt the password in the client then it's probably going to be in memory for some time so again it's easily vulnerable to an equipped hacker.

I don't know what your motivations are for this design, but I'd like to expound upon what the previous poster has said because I see this kind of question come up a lot. A lot of people seem to think that you can secure a client-server application by putting security checks in the client, and then requiring that the user connect with that software and nothing else. The trouble is, there is no reliable way to ensure that the software that is talking to you is the software you intended. It might have been modified by a hacker, or it might be entirely new software writen by a hacker that appears identical to the original software from the server's side. As the poster said before, any hacker can get to your password, no matter how many times you encrypt it, because you can't keep the hacker from also extracting the decryption algorithm. So, the best security model is one where the server makes no assumptions about the software that is connecting to it. In security terms the software should be designed to trust the user, not the client software. That means the server should make decisions about whether to honor a request based on a verified user identity, reguardless of the software he/she is using.

That said, there is nothing necessarily wrong with making it difficult for a person to connect with a different client. Just realize that it can and will be circumvented if any hacker has even a little motivation to do so. Too often it is used in place of a proper security model, and it creates a false sense of security that is easily circumvented.

PS- It might be possible sometime in the future, when there is hardware support for this kind of thing, to actually secure a client-server application by authenticating the identity of the client software, rather than the user. At the moment, however, no such platform exists that is readily available.

The real question is:

If the person doesn't know the client programs passwords, why is the client program even sending them to the server? Unless you are suggesting something where every copy of the EXE has a different username/password compiled into it, what practical purpose does it serve? What are you trying to accomplish?

Perhaps you should provide some more insight into what kind of server this program is connected to. You do realize that a user can *easily* tap any communication between the client program and the server. Only a fool would waste time taking apart your EXE looking for a password or authentication token if he can just sniff the packet sent when the client program starts.

In a nutshell, this is a web-service that the application needs to log into. The data that is presented is application specific, not user specific. There is no 'target' application, only a target usage. It is this usage I am trying to protect.

The purpose is for the user of the application to have no knowledge of the authentication process. The web-server only needs to know what application is connecting. There does not necessarily have to be a username/password. It could be a GUID etc.... All I need is for the key to be secure, or as secure as I can get it, on the client machine.

It's more the updating I'm concerned about..

You're basically suckered in that scenario.
You've no way to prevent someone at some point from getting at your password.

All encrypting it in the exe and then decrypting it at some point does is make it slightly harder, but a simple portlistener on the network would still find out what's being sent!