Sign in to follow this  

Plain text passwords in an EXE

This topic is 4308 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
What harm comes from simply not authenticating? For example, if your game connects to some server to get a world-wide ranking for the player, and someone writes an app that gets this ranking so your user can look at it while not actually playing, does this harm you?

Share this post


Link to post
Share on other sites
If you distribute a program that can tell the server a new score, then anybody that gets the program can tell the server a new score by reverse engineering the program. Nothing you can do can prevent that. The best you can do is make reverse engineering difficult, but you have to learn reverse engineering to know how to do that (or you could contract somebody else to do it for you, such as those companies that sell the commercial anti-piracy systems).

One easy way to make scores difficult to fake would be to send a log of the gameplay (the info you'd need to replay what the player did) instead of the score itself, and the server would replay the game using that file and record the score it calculates, but even that isn't hack proof.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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!

Share this post


Link to post
Share on other sites
Decrypting it in on the server doesn't help either. As the hacker, I wouldn't even bother with the password. I'd just write down my score; sniff the packet; find that number in it; change it and send it again.

Share this post


Link to post
Share on other sites

This topic is 4308 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this