Re: SMTP AUTH implementation question

From: Ronald F. Guilmette (rfg_at_monkeys.com)
Date: 03/01/04 

Date: 1 Mar 2004 11:05:25 -0800

Foo Bar <foobar965@hotmail.com> wrote in message news:<muC0c.84643$dP1.233839@newsc.telia.net>...
> rfg@monkeys.com (Ronald F. Guilmette) writes:
>
> <SNIP description of CRAM-MD5>
>
> > What I _cannot_ do is to figure out how to verify the mish-mash in the
> > case where all I have, on the server side, is something like an /etc/passwd
> > file, where the passwords are NOT stored in plain text, but rather in
> > pre-hashed form.
>
> You can not verify it without having the password in plaintext on the
> server.

OK. Thanks. That was pretty much the conclusion that I had come to on my
own, but I needed to have somebody verify it for me (because a lot of this
stuff is rather confusing for me, and I don't yet trust my own conclusions).

>The specification talks about a _shared_ secret.

Yeabut that term could have a number of different meanings.

In some sense, both a user who is logging in to a UNIX machine and the
machine itself both ``have'' the password for the relevant account. It's
just that in the case of the machine, it only ``has'' the password in
post-tripleDES form. (1/2 :-)

P.S. I wonder if I'm the only one on the planet who sees this requirement
(i.e. for storage, on disk, of the plaintext passwords) of the CRAM-MD5
SMTP AUTH mechanism as being a downside of this specific mechanism. I have
already implemented the (non-standard?) PLAIN and LOGIN mechanisms, on the
server side, and for these, at least, I can make them work with the server's
local /etc/passwd file and the tripleDES passwords stored therein, whereas
as I have just learned, this can't be done for CRAM-MD5.

I do know that the downside of PLAIN and LOGIN is that with those, you
potentially have plain text userIDs and passwords going over the wire,
and that this is probably even *more* risky than having plaintext passwords
stored on some well-secured disk drive, but one can always implement a
TLS encryption layer, and then implement the PLAIN or LOGIN SMTP AUTH
methods underneath (on top of?) that, thus providing good security for
the stuff going over the wire.

All things considered, PLAIN and LOGIN, when combined with TLS, would seem
to be in some sense "better" than CRAM-MD5. At least in the former case,
the stuff can be made to work with existing UNIX /etc/password files.

Any disagreement?

Relevant Pages

  • Re: questions on setting up a mail server
    ... standard method built in to the protocol) require Cyrus SASL. ... use your existing user passwords. ... passwords held in plain text - the sasldb. ... PLAIN is the preferred protocol according to the docs and RFCs - LOGIN is ...
    (freebsd-questions)
  • Re: WindowsXP plaintext passwords on LAN
    ... Searching for "plain text passwords" at www.microsoft.com returns this as the third item in the search results. ... > Please reply only to the newsgroup so all may benefit. ...
    (microsoft.public.windowsxp.security_admin)
  • RE: ipopd plain text passwords
    ... Just an update and again Thank you both Pim and John for your suggestions. ... when I install ipopd it doesn't include the LOGIN authentication module. ... Subject: ipopd plain text passwords ...
    (Debian-User)
  • Re: How to save internet login and password
    ... Now would be a perfect time to document and store said login ID's and ... passwords in a secure location. ... They are not stored in plain text on the ...
    (microsoft.public.win2000.general)
  • Re: Windows Server 2003 and Lanman98 / Omni
    ... Windows to accept plain text passwords. ... Microsoft network Server: Digitally sign communications set to ...
    (comp.sys.acorn.networking)