* [sup-talk] Encrypted password in configuration file
@ 2009-08-24 20:54 Lars Kotthoff
2009-08-28 2:37 ` Jim Cheetham
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Lars Kotthoff @ 2009-08-24 20:54 UTC (permalink / raw)
Hi list,
is it possible to store the account password encrypted in the configuration
file?
Thanks,
Lars
^ permalink raw reply [flat|nested] 7+ messages in thread* [sup-talk] Encrypted password in configuration file 2009-08-24 20:54 [sup-talk] Encrypted password in configuration file Lars Kotthoff @ 2009-08-28 2:37 ` Jim Cheetham [not found] ` <20090828012502.15484x8musndy5mo@webmail.seas.upenn.edu> 2009-08-28 7:23 ` Lars Kotthoff 2009-08-28 20:29 ` William Morgan 2009-08-28 22:48 ` Mike Kelly 2 siblings, 2 replies; 7+ messages in thread From: Jim Cheetham @ 2009-08-28 2:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <20090828012502.15484x8musndy5mo@webmail.seas.upenn.edu>]
* [sup-talk] Encrypted password in configuration file [not found] ` <20090828012502.15484x8musndy5mo@webmail.seas.upenn.edu> @ 2009-08-28 7:07 ` Jim Cheetham 0 siblings, 0 replies; 7+ messages in thread From: Jim Cheetham @ 2009-08-28 7:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [sup-talk] Encrypted password in configuration file 2009-08-28 2:37 ` Jim Cheetham [not found] ` <20090828012502.15484x8musndy5mo@webmail.seas.upenn.edu> @ 2009-08-28 7:23 ` Lars Kotthoff 2009-08-28 9:28 ` Jim Cheetham 1 sibling, 1 reply; 7+ messages in thread From: Lars Kotthoff @ 2009-08-28 7:23 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [sup-talk] Encrypted password in configuration file 2009-08-28 7:23 ` Lars Kotthoff @ 2009-08-28 9:28 ` Jim Cheetham 0 siblings, 0 replies; 7+ messages in thread From: Jim Cheetham @ 2009-08-28 9:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [sup-talk] Encrypted password in configuration file 2009-08-24 20:54 [sup-talk] Encrypted password in configuration file Lars Kotthoff 2009-08-28 2:37 ` Jim Cheetham @ 2009-08-28 20:29 ` William Morgan 2009-08-28 22:48 ` Mike Kelly 2 siblings, 0 replies; 7+ messages in thread From: William Morgan @ 2009-08-28 20:29 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 7+ messages in thread
* [sup-talk] Encrypted password in configuration file 2009-08-24 20:54 [sup-talk] Encrypted password in configuration file Lars Kotthoff 2009-08-28 2:37 ` Jim Cheetham 2009-08-28 20:29 ` William Morgan @ 2009-08-28 22:48 ` Mike Kelly 2 siblings, 0 replies; 7+ messages in thread From: Mike Kelly @ 2009-08-28 22:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-08-28 22:48 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-24 20:54 [sup-talk] Encrypted password in configuration file Lars Kotthoff
2009-08-28 2:37 ` Jim Cheetham
[not found] ` <20090828012502.15484x8musndy5mo@webmail.seas.upenn.edu>
2009-08-28 7:07 ` Jim Cheetham
2009-08-28 7:23 ` Lars Kotthoff
2009-08-28 9:28 ` Jim Cheetham
2009-08-28 20:29 ` William Morgan
2009-08-28 22:48 ` Mike Kelly
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox