Prevent strings stored in memory from being read by other programs

Question

Some programs like ProcessExplorer are able to read strings in memory (for example, my error message written in the code could be displayed easily, even though it is compiled already).

1. Imagine if I have a password string "123456" allocated sequentially in memory. What if hackers are able to get hold of the password typed by the user? Is there anyway to prevent strings from being seen so clearly?

2. Oh yes, also, if I hash the password and sent it from client to server to compare the stored database hash value, won't the hacker be able to store the same hash and replay it to gain access to the user account? Is there anyway to prevent replaying?

Thank You!

Answer 1

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

[edit]

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

Reference: http://en.wikipedia.org/wiki/Public_key_infrastructure

Answer 2

Andrew's answer gives you good hints for protection of in-memory strings. Regarding replaying - you're certainly right that if someone else intercepts the hashed password, they can replay it and compromise security. The way to defeat that is challenge-response authentication: http://en.wikipedia.org/wiki/Challenge-response_authentication