Hi list, is it possible to store the account password encrypted in the configuration file? Thanks, Lars
On Tue, Aug 25, 2009 at 8:54 AM, Lars Kotthoff<lists at larsko.org> wrote:> Hi list, > > ?is it possible to store the account password encrypted in the configuration > file?It''s possible, but slightly pointless. Have a read of Eric Raymond''s discussions about Fetchmail, which has the same configuration data :- http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s09.html "Another lesson is about security by obscurity. Some fetchmail users asked me to change the software to store passwords encrypted in the rc file, so snoopers wouldn''t be able to casually see them. I didn''t do it, because this doesn''t actually add protection. Anyone who''s acquired permissions to read your rc file will be able to run fetchmail as you anyway?and if it''s your password they''re after, they''d be able to rip the necessary decoder out of the fetchmail code itself to get it. All .fetchmailrc password encryption would have done is give a false sense of security to people who don''t think very hard. The general rule here is: 17. A security system is only as secure as its secret. Beware of pseudo-secrets." -jim
On Fri, Aug 28, 2009 at 5:25 PM, <wagnerdm at seas.upenn.edu> wrote:> I can imagine all kinds of situations with "benevolent" attackers. ?For > example, what about a girlfriend that pokes around your hard drive looking > for lolcats when she''s bored? ?One glance at .fetchmailrc would show it''s > not a lolcat; but that same glance could show a password that you don''t > really want her to know.It took over 7 years before I would even tell my wife my login password; I''ve since changed it and won''t share it. And I trust her implicitly with my machine -- there is nothing on there that I''m not happy for her to see :-) So, how does the putative bored girlfriend poke around your hard-drive in the first place, in this scenario? If you are letting her use your account and poke around your machine in the first place, how does her seeing a password cause a problem? If you don''t want someone to know something, don''t put them is a situation where they might find it. You shouldn''t expect a program to employ a pointless encryption/obscuration scheme just because you don''t look after your other data. You are increasing the complexity of the code, increasing the complexity of the testing environment, increasing the opportunity for bugs to occur (possibly causing data loss?), and protecting against nothing. Now, there is an approach used by mutt that sup doesn''t seem to use, which is to prompt the user at the beginning of a session for the various source passwords; this way they are only held in memory (and swap files, probably). That may be a way out of the situation; as a mail client is inherently an interactive program, there''s no harm in prompting for things missing from the config, I think. -jim
> It''s possible, but slightly pointless.Not if the user supplies the passphrase, e.g. it could be encrypted with the user''s GPG key and ask for the passphrase at startup. Lars
On Fri, Aug 28, 2009 at 7:23 PM, Lars Kotthoff<lars at larsko.org> wrote:>> It''s possible, but slightly pointless. > > Not if the user supplies the passphrase, e.g. it could be encrypted with the > user''s GPG key and ask for the passphrase at startup.Why not just ask for the IMAP password itself? There''s no functional difference between that secret, and the secret that unlocks the secret ... indeed, if sup were to accidentally expose the passphrase you provided, would you rather lose your GPG key or your IMAP key? If you are really determined to allow others to read your private files, why not just encrypt the whole .sup directory with a separate tool (TrueCrypt, loopback, rot13, encfs, ecryptfs, or whatever else your distribution provides). That way, you are also protecting the ferret index collection, and the default sent box, which all contain data of the same level of sensitivity as your mailbox. Given your concern, I assume that you will be remembering to terminate sup and dismount the .sup directory every time you walk away from the keyboard. (Many schemes these days encrypt the whole of $HOME, which makes the whole screensaver/away from the keyboard thing even more difficult). Security must be appropriate to be actual security. Otherwise it''s just an expensive fa?ade. -jim
Reformatted excerpts from Lars Kotthoff''s message of 2009-08-24:> is it possible to store the account password encrypted in the > configuration file?Despite generally agreeing with Jim''s argument, I''m happy to accept a patch to do this. -- William <wmorgan-sup at masanjin.net>
On Mon, 24 Aug 2009 21:54:35 +0100 Lars Kotthoff <lists at larsko.org> wrote:> is it possible to store the account password encrypted in the > configuration file?Along the lines of what Jim said, doing any sort of two-way encryption on the password is a wasted effort. There are other sort of authentication mechanisms which are probably more appropriate (certificate-based, Kerberos/GSSAPI, ...). -- Mike Kelly