I'm pretty sure that this wouldn't be safe. By simply disassembling the software you would see the strings stored in the application itself, so you could easily find any password stored that way.
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.
And even with all that I probably screwed something up, but that advice is still better than storing plain passwords.
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.
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.