[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mutt or KMail



On  0, "Bryan K. Walton" <thisisnotmyid@tds.net> wrote:
> On Sun, Aug 25, 2002 at 4:32:45PM +0100, Karl E. Jorgensen wrote:
> 
> >> The one disadvantage I see from letting fetchmail retrieve is that
> >> there doesn't seem to be a way for fetchmail to store email passwords 
> >> on the computer using encryption.  Perhaps I am wrong (please tell 
> >> me so) but unless you supply your password every time you check for mail,
> >> passwords are kept in plain text.  
> >
> > !? What's the point of using encryption here? If the code is open
> > source, then the algorithm cannot be secret; only the encryption key.
> > Which leaves you with having to enter a decryption key. Back to square
> > one.
> > 
> >     http://www.tuxedo.org/~esr/fetchmail/design-notes.html
> > [search for "password encryption"]
> > 
> >> That may be fine if your mail account is the only one fetchmail will
> >> retrieve mail for.  But if you have other users who don't want you to
> >> know there password, you have a problem.
> >
> > c/there/their/ ?
> > 
> > Problem is easily solved by:
> > 
> >     chmod go-w ~
> >     chmod go= ~/.fetchmailrc
> > 
> > which is the way it should be IMHO.
> 
> No problem.  I agree with both you and Eric's ideas behind this.
> However for me, that's not the issue.  There are end users
> out there that don't want to put there passwords into an ascii file in
> plain text.  With all due respect to ESR, the issue isn't whether
> someone with root access can decode an encrypted password.  Many people
> refuse to store passwords in plain text on there machine.  And they
> refuse to accept the notion that it can't be encrypted when almost every
> email program on the planet can store passwords encrypted, then
> successfully decrypt and send them across a network to retrieve mail.  I
> used to work for an ISP in Madison, WI and we didn't store user
> passwords in plain text on our mail server.  It wasn't a matter of
> efficiency.  It was 1) users wanted encryption. 2) If the mail server
> was ever compromised, a lack of decryption would have made customer passwords
> a little bit easier to collect. Our mailserver wasn't using fetchmail
> in any way, and it wasn't compromised, but the point is the same.  

The point is not the same.  On your mail server you store a hash of
the password, NOT an encrypted password.  That hash is enough for a
server to be able to tell whether someone is using the correct
password, but is not enough to authenticate with another server.  I
will not explain hashed passwords here;  there is plenty of material
on the web.  They are different to encrypted passwords.  Encryption is
a reversible operation, hashing is not.

In the end, every reversible encryption is protected by a password.
When someone discovers that password, your encryption is useless.  So
what is the difference between storing the password in plain text with
only user access (ie. protected by your UNIX password) and encrypted
(protected by another password, probably the same one for most users)?

> In my humble opinion, it is a feature that many people want.  Sometime
> down the road, it is a feature that people will get -- if not in
> fetchmail, then in some other program. 

I agree that I am a little uncomfortable with the fetchmail way of
doing things, but I am not sure that there is a better way.  Can you
think of one?

Tom

PS.  Please stop CCing me, I read the list.
-- 
Tom Cook
Information Technology Services, The University of Adelaide

Do not meddle in the affairs of dragons, for you are crunchy, and taste good with ketchup.

Get my GPG public key: https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au

Attachment: pgp6Az0W2BSSf.pgp
Description: PGP signature


Reply to: