In a compiled language, it would be part of the binary. If you opened up "checkpassword.exe" in a hex editor, you'd see the password clear as day somewhere in the static data section.
In an interpreted language, the interpreter would create some kind of string object containing the contents of the password in memory, and getPassword() would return that object when called.
Even simpler, Unix has a tool called "strings". Call it on any piece of data and it will return all readable strings contained in that data. Works on binaries as well.
You should never store a password. If absolutely needed you could store a derivation of that password from a KDF like scrypt, and then see if the user's password derives to that same value. This is how checking for login passwords is done on Unix and Unix-like systems with shadow passwords (which never store the user's password).
And even with all that I probably screwed something up, but that advice is still better than storing plain passwords.
Nobody ever thinks of the case where a program has to supply a password and not just check it. For example, suppose your program (that runs unattended) has to interact with some JSON-RPC API, and the remote server expects a password. That password has to come from somewhere.
You should use public-key crypto for this case when possible. Any key you bake into the binary will be a publically-known password for anyone who gets access to that binary. With public-key crypto it's safe to include the public key and then make an ad hoc session key using secure key exchange.
You actually could get this from memory while the program is running, but even if it weren't, you could get it by using a hex editor. If you've got access to the "strings" command, that will also usually work for things like passwords.
ah ok, so what is the recommendation for storing password in a scripting language like
Ruby, Python, RingoJS, NodeJS, PHP, etc? Don't think they have fancy function to determine to store the variables in CPU register or encrypted memory?
I got the feeling that all these should have being taken care of on the hardware level, but someone just got too lazy during the design process and forgot to patch up the security flaw.
Kinda like how everyone was still using telnet to get into their *nix servers in the 90's.
The way it generally works is you keep a user's encrypted pass with a unique per-user salt stored on disk (usually in a database of some sort). When you need to authenticate a user, your script will ask the user for their password. Then, you encrypt this input pass with the stored salt. Finally, you compare the encrypted input pass with the original encrypted pass on disk. If they match, you're good. At no point do you store passwords on disk that have not been encrypted (via bcrypt or similar). Depending on the security needed (i.e. your threat model and risk) this can get tricky if things like hibernation or virtual machines are involved.
If you're confused at all about this, I would browse the security forums (http://security.stackexchange.com/) and ask for expert advice.
> ah ok, so what is the recommendation for storing password in a scripting language like
> Ruby, Python, RingoJS, NodeJS, PHP, etc? Don't think they have fancy function to determine to store the variables in CPU register or encrypted memory?
You shouldn't need to store passwords (or any sensitive info) in memory. In fact, you shouldn't store passwords at all. Normally, you would put the password in memory temporarily (for hashing or something), and then you would securely wipe it when you are done.
Failure to wipe memory (or use it improperly) can have awful consequences. IIRC, that was how the Target hack worked. Basically, the attackers were able to search through memory and dump credentials.
You should use wrappers for trusted/vetted libraries (like Crypto++ or something). I know for a fact that Crypto++ has a concept of "secure buffers", whose contents are securely erased before destruction. All libraries of that sort should wipe any sensitive information from memory (by overwriting it with garbage or zeroes) before freeing it.
That particular library probably does not have wrappers for other languages. However, GnuTLS and OpenSSL probably do.
