A safe way to store a password.

RonMexico used Ask the Experts™
Hello, we are making a program and part of it needs to be protected by a password.  The password will be modifiable, saved to disk, loaded from disk to RAM, and kept in RAM to compare to user entry.

I haven't had occasion to research this much, so looking for some pointers: what are the ways to design this (very typical mechanism) to be cyber-secure, aka hacker-proof?  

Of course when we save the password to disk we will encrypt it somehow, and also disguise it as part of something else (i.e., we will not have a config file called "password.txt").  But I also have heard that hackers have ways to get at passwords when they are stored in RAM at login time for comparison purposes (don't know precise details, but I presumed it had to do with using buffer overrun exploits and the like to get chunks of RAM, and then somehow they deduce the password data).

Anyway, I'm looking for ideas on protecting both (a) the disk storage and (b) the loading/using in RAM -- unless someone can convince me that I was sold a bill of goods and hackers can't get the RAM.  

Thanks for any thoughts or (specific as possible) research pointers for this.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
You'll probably use XOR to encrypt the bytes in a password string, or some method to create an encrypted version of the plain-text password.

Hacking an encrypted bit of software is not difficult with debuggers but you can add some features to your code to add a "time bomb" to the functionality of the program based on finding that the program code has been changed in the area where you do the testing (they'll often find a jmp statement (conditional or otherwise) that bypasses the test after filling in something indicating that the password was checked and is okay. If you can run a checksum on your EXE file itself during startup, to detect such changes in the code, that helps know if someone has been fiddling with the machine code.

During installation, you might want to have a setting in the registry, or in an ini file, to indicate some relatively non-remarkable issue, like KBDTYPE or CAPSLOCK and set it to some value.

If you do detect compromised code, you might consider changing a registry or ini file setting, but don't crash the program or complain at this point, but you could exit gracefully with an error code with some nonsense like "not enough FCBS found" or "ERROR 4100: insufficient QLS" and wait for the phone calls.

Note this error code in the registry or ini file somewhere.  Use it as a clue that something has gone wrong. Code that has been modified is a violation of almost everyone's license agreement, so don't feel bad about this if someone gets caught.  Just don't issue the message in the same area of the program as the compromised code was detected, have it popup in a different section of code, or several sections that occasionally, not every time, check for this compromise situation. Different error codes will add to the fun of catching these thieves. Having done similar things, I've noticed that they rarely will call for help, so an alternative is to tell the user "There is a new version, please visit xxx..com/yyy.htm and enter this code to download a newer version"  -- of course the new version can require an e-mail address (which can be dummied up so don't depend on it's validity) but record the IP address of the incoming request, and do whatever you wish at that point with the user who wants the free update.

Once you've given it a try on your own, you may want to invest in some programs that will help you. check here:  http://www.developer-resource.com/how-to-protect-software.htm

Don't depend on one solution, add your own as well as a 3rd party solution.

Think like a hacker to defeat a hacker.


"You'll probably use XOR to encrypt the bytes in a password string, or some method to create an encrypted version of the plain-text password."

This sounds like that specific part I was asking about... what does it meant to use XOR encryption?  Then do you agree then that it is important to protect this even for the short period its in RAM?  Then I also imagine its important that value is not in RAM for any longer than necessary?

I actually hadn't thought about a hacker maliciously modifying the code itself -- that's what the rest of your response is proposing a defense against, is that correct?
A XOR encryption is one of the weakest solutions.

Normally you must not save the password or an encrypted version of it.

It is better to use a Hash Function and save only the password's hash value.
When the user about to be authorized, you just use the same hash algorithm an verify the result with the stored value.

By this you can never decrypt a password from your password file.

Typical Hash algorithms are MD5 or SHA1



XOR is a simple way to flip every bit in a byte or word to the other state. Or to flip only certain bits, or to run a string of bytes, one by one, against a password string of bytes.

  For example:    10011001 might represent some byte in a string
If you were to XOR (exclusive OR) this with a byte that looks like this "01001011"
it would flip bits that have a value of 1 leaving the others alone

10011001  byte
01001011  key
---------------- xor
11010010  would be the "encrypted" result

now xor this with the original "key"

11010010  encrypted
01001011  key
--------------- xor
10011001  result

Notice after doing the XOR logic the final result looks like the original value

Lots of variants on this, like using a pseudo random number function that produces a known output of "random" bytes given a starting key value, and using the XOR of the original string of bytes with this string of so-called "random" bytes will produce an "encrypted" result that looks nothing like the original string.

The advantage of these more complex approaches is that they still use XOR which can be used to recover the original string IF you know the key and it is extremely fast in code, and even if the original value is a string of spaces, the output will look like a string of random bytes.

More complex schemes also involve interchanging every other byte after the XOR, and then interchanging the encrypted string bytes just before "decoding" the string.

Okay, enough on XOR, look up the function in C code, under "exclusive or" - it's one of the bit manipulating logic operators in the category that includes AND, OR, NOT, and XOR.

As for keeping the unencrypted key in memory, not so sure, but you can apply this XOR multiple times, so encrypt the password and save in memory, then unencrypt it if you want to use it, or encrypt what the user types in and compare.  If you XOR then XOR then XOR all with different "encryption bytes" you can back out and get the original byte by reversing the order of the XOR. XOR is actually commutative, like in addition when A+B+C = A+C+B, it turns out that  A ^ B ^ C is the same as A ^ C ^ A (the XOR bitwise operator in C is ^ ).  This can add some fun to the process, eh?

In the old days I used to write self modifying code using a feature of the processor that stores instructions in the instruction queue and use the queue length to make changes that are missed by the reading of instructions from memory. I'm sorry I can't recall the details, that was years ago when I was doing more of this software encryption stuff, which by the way is no longer allowed in some applications. They want only hardware encryption, so we don't use the term "encryption" we call it bitwise string modification. 'nuff said.

You will see some programs that check themselves before they'll run. This is not a bad idea, but it sends the message to a hacker about where to look, and the results of such a test can be found and sometimes defanged so to speak, using NOP or a JMP instruction to bypass the negative results of a potential program failure if the developers find it has been modified. Best not to advertise how you're protecting your program.

I did a program years ago that would wait about a week before it killed itself, and no hacker is going to sit around for a week waiting for the program to find that it's been modified, so we had little if any theft of software programs. It also detected if the user was screwing around with the date/time of the computer, and put a poison pill in the software that flagged a potential problem if the clock setting scheme was used too often.

Think like a hacker.

I was creating this response when the other expert suggested a hashing approach. I like the hashing approach too. See http://www.md5hashgenerator.com/index.php and type in a password to see what a hashed value looks like.  A single XOR byte is weak, no doubt, but with some extra work and using pseudo-random keys etc., it can be quite difficult to decrypt.

It's good for passwords, or generating a key for an entire file, but it doesn't have a way to recover the original data, if that's important. It might not be important for just passwords and checking the original file.

I just found a good explanation of XOR cypher. My application involved "encryption" not just verifying, and as this article points out, using random number keys etc., makes this very difficult to break, so it may be a weak encryption scheme with a single encryption byte, but it quickly becomes nearly impossible to break with the other tricks I explained earlier.  Check this out:  http://en.wikipedia.org/wiki/XOR_cipher

Trivia: United States National Security Agency documents sometimes use the term combiner-type algorithms, referring to algorithms that use some function to combine a pseudorandom number generator (PRNG) with a plaintext stream.  (from Wikipedia)


RonMexico -- are you able to use any of the information provided to answer your question?  Next step -- assign points, if any??



Update: Thanks for the points !!


Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial