I believe you are confusing two things. The strings ProcessExplorer is finding are also able to be found by the "strings" command in Unix. It just dumps all the stored strings in an executable not the current memory.
Unless you compiled a User password into your program, the memory allocated to store the data shouldn't be read by ProcessExplorer.
There are numerous issues that can occur. Your best bet is to ensure that no other code can run within your process space. Since the days of virtual memory, each process gets its own virtual memory space, ideally preventing any other program from accessing and messing with the memory of other programs. There are ways to detect if your program is being debugged.
You also need to ensure that the memory you are using to store the password is never written to disk or paged out. This web site can point you in the right direction. https://www.securecoding.cert.org/confluence/display/seccode/MEM06-C.+Ensure+that+sensitive+data+is+not+written+out+to+disk
I wanted to expand upon my previous post by talking about replay prevention.
If you are truly serious about a complete solution you will need to implement two-way authentication using a PKI system. Your client will have a certificate and so will your server. The client's private key will only be able to unlocked with a password the user will enter. This will allow the server to verify the the client is who he says he is. The client will then verify the server is who he says he is the same way as the client.
By using this system you prevent someone from possing as a server and attempting to get you to send it your password.
This is a topic I can't cover too well on this web site. You will need to research Certificate Authorities and PKI.
Your vulnerabilities are then:
1. Peaking into current memory to extract the password
2. Social engineering