Scott Gifford writes:
> Gabriel Ambuehl <[EMAIL PROTECTED]> writes:
>
> > Hello Scott,
> >
> > Monday, July 03, 2000, 5:54:00 PM, you wrote:
> > >> May anyone explain me what sense a SSL tunnel for POP3 does have (I've
> > >> been wondering about that for long...)?
> > > [ ... ]
> > > To protect the POP password.
> >
> > But wouldn't it be way easier to just use APOP? Or does that one have
> > its own security implications?
>
> The only particularly nasty implication of using APOP are that it
> requires that the server have the password stored in plaintext. The
> security aspect of that is that if somebody can steal the password
> file from a system, they have direct access to all accounts, compared
> to storing one-way hashes of passwords, which would make them run
> crack first and they still wouldn't get well-chosen passwords. The
> maintainability aspect is that standard UNIX passwords aren't stored
> in plaintext, so you can't use APOP to authenticate against a standard
> UNIX passwd file.
The APOP password only controls access to the e-mail POP account. It
DOES NOT have anything to do with a UNIX login account! In fact, if you
allow both shell and pop access, snooping the POP password gives you the
shell password, whereas you can set a single APOP password that gives
access to e-mail and has absolutely nothing to do with shell access.
Thus, in spite of (or because of) the clear-text APOP password storage
on the server, you cannot compromise anything except e-mail by
discovering the APOP password.
> POP over SSL solves both of these, by making no changes to the POP
> protocol, but just encrypting the whole session.
SSL for e-mail (especially POP) is extreme overkill, causing untold
client and server configuration difficulties for little or no effect,
seeing as SMTP is unencrypted...
/Joe
