I have recently taken a security course, and have learned a lot about, among other things, the way passwords are stored, etc.
Afterwards I was thinking about the way that passwords are stored for email clients. If we provide our email clients with passwords for our accounts, those clients must save those passwords somewhere, and could only save them in plaintext. This would be the same for any client on a computer, smartphone, tablet etc.
I was wondering how much of a risk is this considered?
The user account password is stored somewhere "on the user". The user is theoretically responsible for protecting his own password. Ideally, he keeps it in his head and types it again when needed.
Some (most) users won't like it, and will instead enabled the "remember password" button, which will make the email client remember the password. If the email client is reasonable and runs on a reasonable operating system, this storage can be somewhat protected. For instance, on MacOS X, using Apples "Mail" application, account passwords will be stored in the user's Keychain, which is stored encrypted, the decryption key being the main user password (the one he types to open a session or unlock it). That way, the email account password is never stored as plaintext equivalent; an attacker stealing the complete hard disk of the machine will not immediately find it. (But it won't save the user against an hostile but discreet hijack of the machine, because of, at least, key loggers.)
Some other applications and/or operating systems won't be as reasonable as that.
Among possible mitigations:
Each user shall have his own account and password. This one, you already do. This ensures that a stolen password unlocks the account of only one user, which is better than nothing.
The email account password could be specific to email, and not be used anywhere else, in particular not to open SSH or RDP sessions. Users won't like it (they really prefer remembering one password than two). Also, most "password reset" systems fall back on email, so stealing an email account password can open access to a lot of other systems.
Implement one-time passwords. Hardware tokens such as this one are granted to users. Email applications won't have anything to save poorly.
However, user education is of paramount importance.
If the machine is compromised then all passwords that are typed in can be obtained using a keylogger. Dumping passwords from memory is a possibility, and this is not a problem cryptography can solve. For example, browsers will encrypt passwords that are saved and this is trivial to bypass.
The problem is using a compromised machine, and not having an anti-virus. There is nothing an email client can do about this.
It is worth noting that generally the stored passwords should still not be stored in plain-text. If things are done correctly, they should be tied to the user's account credentials. This doesn't do anything to prevent the passwords from being retrieved if the user is logged in, but it does prevent them from being retrieved when the user is logged out (provided that the mechanism is otherwise secure.)
For example, on Windows, the CryptoAPI provided by Windows allows for storage of various keys and secrets for a user's account. When the user logs in, it generates a key that allows the user's keyring in the CryptoAPI to be unlocked. When the user logs out, this key is discarded and the keyring can't be accessed unless the user logs in again.
That said, there is also no guarantee that a program won't use an insecure method to store the password even if the facilities are available to tie it to the user's main login. Also, if the computer is setup to require no password to login, then it will always be insecure.
