There is much debate on this. While Neil's answer is correct, storing any credentials on your computer is inherently risky. Even if you encrypt them and store them in a unique location, software you run needs access to the encryption key(s). If you enter the encryption keys every time (or a password to unlock them or similar), it may be just as easy to enter the credentials.

This problem is not unique to passwords. Un*x tends to rely heavily on file permissions (access control) but they cannot differentiate one process running as user from another. SSH private keys stored in ~/.ssh are also a risk, for example.

The main benefit to a standard location for credentials like .netrc is keeping them separate from scripts or other programs that use them. For example, if you write a shell script that automates an FTP session, embedding the user name and password in the script instead of a .netrc file may lead to the credentials inadvertently being shared as the script is stored in source control or copied to other systems.

Using a central location like .netrc also allows individuals to have their own credentials for accessing systems. Shared accounts are frowned upon because it activities cannot be attributed to an individual. Otherwise, individuals need their own copies of scripts.

The second benefit is only having a single place to update changed credentials. If multiple scripts or programs use the same but old credentials, you can lock out accounts. Changing the .netrc file can update multiple scripts or programs at the same time.

That said, encrypting passwords at rest prevents inadvertent access to passwords, such as through backups, shoulder surfing or similar. If you must store credentials on a system, consider something like an encrypted store over the plaintext .netrc file if one is available. For example, git now supports encrypted .netrc files.

There is much debate on this. While Neil's answer is correct, storing any credentials on your computer is inherently risky. Even if you encrypt them and store them in a unique location, software you run needs access to the encryption key(s). If you enter the encryption keys every time (or a password to unlock them or similar), it may be just as easy to enter the credentials.

This problem is not unique to passwords. Un*x tends to rely heavily on file permissions (access control) but they cannot differentiate one process running as user from another. SSH private keys stored in ~/.ssh are also a risk, for example.

The main benefit to a standard location for credentials like .netrc is keeping them separate from scripts or other programs that use them. For example, if you write a shell script that automates an FTP session, embedding the user name and password in the script instead of a .netrc file may lead to the credentials inadvertently being shared as the script is stored in source control or copied to other systems.

Using a central location like .netrc also allows individuals to have their own credentials for accessing systems. Shared accounts are frowned upon because it activities cannot be attributed to an individual. Otherwise, individuals need their own copies of scripts.

The second benefit is only having a single place to update changed credentials. If multiple scripts or programs use the same but old credentials, you can lock out accounts. Changing the .netrc file can update multiple scripts or programs at the same time.

That said, encrypting passwords at rest prevents inadvertent access to passwords, such as through backups, shoulder surfing or similar. If you must store credentials on a system, consider something like an encrypted store over the plaintext .netrc file if one is available. For example, git now supports encrypted .netrc files.