[blt]

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.

[Morgawr]

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.

[treenyc]

good to know. I guess the best thing is to NOT store password at all in the the code? Rather in encrypted databases?

[mpyne]

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.

[lkjsdflkj]

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.

[mpyne]

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.