A first important note: if you
can avoid the need to decrypt the password, you should. For example, if it's just to compare user input to a previously stored password, you should not use an encryption/decryption algorithm, but a hashing algorithm or a key derivation algorithm so someone can't just recover the original password. For this purpose, take a look into bcrypt or PBKDF2.
Of course there are purposes where you do need to decrypt it - for example, when you need to pass it as part of a web request. For that purpose, the best way to store the password depends on the operating system:
If you're talking about a Windows desktop application, you should use the CryptProtectData API, which stores the credentials in protected memory regions and encrypts them with a key that is part of the user profile. This is the standard protection mechanism for Windows applications.
On Linux you could look into using the GNOME keyring or KDE wallet, and OS X has a set of APIs for its keyring too. This would ensure that the security settings for the user's keyring take overriding control - they can decide how often they want to have to re-enter their master key.
Any procedure you choose to obfuscate passwords is an exercise in futility against any half-determined attacker, so at most you're creating an illusion of security. My suggestion is to include a setting that says "remember my password", but warn your users that the password will be stored locally in a reversible format that offers little security, so that they're aware of the issue.
For a Linux or a Mac I can't provide an example. If you're using Windows and want to see an implementation of the CryptProtectData API: I have
an article[
^] of which the CryptProtectData API is a part: you'll be interested in the "EncryptDecryptData - for encryption and decryption using CryptProtectData" section of the article.
Submit an article or tip