CODEWITHSUNDEEP
c++securityhashmfcreverse-engineering
jwsc
jwsc

Reputation: 955

Security of sha1 hashed password in memory

My program allows the user to input a password. The password is immediately hashed with sha1 and a constant salt and stored in memory. Lets assume an Attacker has physical access to the computer where my application runs, and wants to retrieve the password of the last user.

Would it be possible for him to find the hash in memory with reverse engineering and some memory watch magic? My Application uses a MFC graphical interface and runs on Windows. What would he see if he himself puts in a password? could he monitor the hashing process?

If the password of my user is really bad, like "1234", all the security of the SHA1 hash depends on the SALT. The salt must also be stored somewhere in memory (its a #defined char* array right now). Could he find that with adequate effort?

Input process:

User enters password in a text edit. When done, user clicks "OK" button, BN_CLICKED message gets emitted, OnOK function is called. The function grabs text from edit field, calls hash function, which is (in code) part of another library, so I assume it must be placed somewhere else in memory. Hashed String gets stored also somewhere else. If it matters, the project structure looks like this:

Upvotes: 1

Views: 396

Answers (1)

Asesh
Asesh

Reputation: 3361

If you reverse engineer Win32/MFC applications then you should notice those data are stored in .data section while const data are stored in .rdata section, not unless the developer has explicitly created another section to store those data. I use OllyDbg for reverse engineering applications though IDA is the best one out there. Now to answer your question:

Would it be possible for him to find the hash in memory with reverse engineering and some memory watch magic? My Application uses a MFC graphical interface and runs on Windows. What would he see if he himself puts in a password? could he monitor the hashing process?

A: Yes, it is possible to find the hash in memory with reverse engineering. You just have to find the memory address of that data. Any reverse engineer/hacker can put a break point in GetDlgItem/GetDlgItemText and then capture the entered password and monitor the hashing process.

If the password of my user is really bad, like "1234", all the security of the SHA1 hash depends on the SALT. The salt must also be stored somewhere in memory (its a #defined char* array right now). Could he find that with adequate effort?

A: It requires very little effort to find the SALT too. One can easily go through those sections or use the technique that I mentioned above to debug and find out the SALT while monitoring the process.

If you are really worried about securing those data then you should consider using encryption. I hope that answers your question

Upvotes: 1

Related Questions