* [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
* [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