As with all security, you need to consider two things: (1) threats and (2) cost-benefit. For example, storing an encrypted password in a config file using symmetric cryptography relies on the file's access permissions and key management.
This may be possible on a web server. After all, the web server can run in a single, low permission account with either (1) read access to the config file and a key store or (2) access to a component that does. Microsoft, for example, supports the former.
However, a traditional application running on Windows, Mac or Linux is different. The user is likely an administrator or have administrator access (e.g. sudo or UAC), meaning he or she can either access the config file and key store or grant themselves access. Anyone with physical access to the storage can also bypass any access control.
Should you use a different form of encryption like asymmetric cryptography? Asymmetric cryptography gives you two keys, meaning data encrypted with one can only be decrypted with another. Since the application will need access to the decrypted password, it needs access to one of the keys. Asymmetric encryption will only remove the ability to encrypt a new or changed password.
Asymmetric encryption may be useful as part of a digital signature to detect tampering. However, a local administrator will have access to the key store used for the digital signature.
You do not specify the encryption algorithm you use but using a stronger algorithm (e.g. wider key, encrypt iteratively) but this only helps if an attacker gets access to the config file and not the key store then tries to brute force it.
Should you store the password somewhere else? This is an operating system and environment dependent question. You could use dedicated hardware, e.g. Trusted Platform Module (TPM) or Hardware Security Module (HSM) but these are topics unto themselves and are likely to be too expensive and complex for most cases.
A better solution may be to trust a third party authentication provider, e.g. via OpenID. This means the application need not manage passwords and customers need not remember yet another password. The third party provider may also provide a second factor (e.g. one time password) and handle password changes and resets.
However, the application risks a compromise to that third party authentication service. Local administrators can also view or modify which third party provider is trusted.
Without knowing more about what you are doing, I would do as you say, i.e. encrypt the password with symmetric encryption in a config file with appropriate permissions. It covers the 90% case without impacting the customer or your development schedule too much.