Subject: [sup-talk] Encrypted password in configuration file

From: [email-masked] (Lars Kotthoff)
Date: Mon, 24 Aug 2009 21:54:35 +0100

Hi list,

 is it possible to store the account password encrypted in the configuration
file?

Thanks,

Lars

---

From: [email-masked] (Jim Cheetham)
Date: Fri, 28 Aug 2009 14:37:48 +1200

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

---

From: [email-masked] (Jim Cheetham)
Date: Fri, 28 Aug 2009 19:07:02 +1200

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

---

From: [email-masked] (Jim Cheetham)
Date: Fri, 28 Aug 2009 21:28:28 +1200

On Fri, Aug 28, 2009 at 7:23 PM, Lars Kotthoff<lars at larsko.org> wrote:
> 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

---

From: [email-masked] (Lars Kotthoff)
Date: Fri, 28 Aug 2009 08:23:49 +0100

Lars

---

From: [email-masked] (William Morgan)
Date: Fri, 28 Aug 2009 13:29:03 -0700

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>

---

From: [email-masked] (Mike Kelly)
Date: Fri, 28 Aug 2009 18:48:59 -0400

On Mon, 24 Aug 2009 21:54:35 +0100
>  is it possible to store the account password encrypted in the

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