Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----

On Sun, 16 Mar 1997, David Summers wrote:

>
> I am probably missing something but I just can't figure it out:
>
> I'm trying to implement an APOP POP3 server on Linux(Unix) and according
> to the RFC1321 and the POP3 RFCs the server is supposed to compare the
> MD5 hash of the server challenge + password with the hash received from
> the client response.
>
> Problem: The Unix password is encrypted and the client password is not
> encrypted. On the SERVER SIDE, how do I find out what the un-encrypted
> password is so I can add it to the challenge and MD5 hash it?
>
> It is probably blindingly obvious to everyone but me....(sigh)....
you can't.

I've not looked at the APOP stuff, but if there is no way to recover the
unencrypted password then it's actually pretty pointless

protocols such as RADIUS use a common shared secret to prevent users
sniffing on the dial-in box / authentication server. the shared secret
is the password, but both ends have it in the clear.

Protocols such as ssh make use of public-key/private-key mecanisms.

I normally run IMAP in pre-authenticated mode over a ssh connection,
though I'd be interested in being able to do this sort of things for
pegasus Mail users on pC's :-)

RjL
+----------------------------+
| richard@illuin.demon.co.uk | Aut viam inveniam aut faciam
+----------------------------+

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBMyxk/Z6bDk8vHTn1AQHFOwP/cMoWurODQ7tSk5guBpT2jNFucKTS6bM6
8ud2dybH9iQ9sdy/QqwJyQOWOVCpYr4U7TYw8Sdb7ryzpW79ZB+vM+yAS/dExsiQ
C5eDfasFtA9/Kf0jeZRrxY+0VURNlNf/L+d8yYD0rTHk9TH3ivR9oV+UZJL5lKSw
SVNebm0FsP0=
=Ib2b
-----END PGP SIGNATURE-----

On Sun, 16 Mar 1997, John R Levine wrote:

> Date: Sun, 16 Mar 1997 18:34:36 -0500 (EST)
> From: John R Levine <johnl@iecc.com>
> To: David Summers <david@summersoft.fay.ar.us>
> Subject: Re: QMAIL + (APOP)/IMAP/POP3
>
> > Problem: The Unix password is encrypted and the client password is not
> > encrypted. On the SERVER SIDE, how do I find out what the un-encrypted
> > password is so I can add it to the challenge and MD5 hash it?
>
> You can't. The Unix password hash is one-way. Perhaps that's why nobody
> else implements this particular verification scheme.
>
> Regards,
> John Levine, johnl@iecc.com, http://iecc.com/johnl, Trumansburg NY
> Primary Perpetrator of "The Internet for Dummies"
> and Information Superhighwayman wanna-be
>
>

Bummer! Well, I'm going ahead and implementing it using the encrypted
Unix password. That is not as nice because the user has to find out what
that is somehow but at least it will make APOP (secure passwords)
possible. I'm getting close to finishing it. I don't know if the
IMAP maintainers will accept it, however....we'll see.

David Wayne Summers "Linux: The choice of a GNU generation."
david@summersoft.fay.ar.us PGP Public Key available on request.
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8

Richard Letts writes:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> On Sun, 16 Mar 1997, David Summers wrote:
>
> >
> > I am probably missing something but I just can't figure it out:
> >
> > I'm trying to implement an APOP POP3 server on Linux(Unix) and according
> > to the RFC1321 and the POP3 RFCs the server is supposed to compare the
> > MD5 hash of the server challenge + password with the hash received from
> > the client response.
> >
> > Problem: The Unix password is encrypted and the client password is not
> > encrypted. On the SERVER SIDE, how do I find out what the un-encrypted
> > password is so I can add it to the challenge and MD5 hash it?
> >
> > It is probably blindingly obvious to everyone but me....(sigh)....
> you can't.

What you do instead for protocols like APOP, CHAP, etc that need a
shared secret is keep the passwords in a file in plaintext. The
passwords should not be the same as the login passwords, to limit
vulenerability in case the file should fall into the wrong hands.

On Mon, 17 Mar 1997, Sebastian Andersson wrote:

> Date: Mon, 17 Mar 1997 08:59:56 +0100 (MET)
> From: Sebastian Andersson <sa@hogia.net>
> To: David Summers <david@summersoft.fay.ar.us>
> Subject: Re: QMAIL + (APOP)/IMAP/POP3
>
> On Sun, 16 Mar 1997, David Summers wrote:
>
> [snip]
> >
> > Bummer! Well, I'm going ahead and implementing it using the encrypted
> > Unix password. That is not as nice because the user has to find out what
> > that is somehow but at least it will make APOP (secure passwords)
> > possible. I'm getting close to finishing it. I don't know if the
> > IMAP maintainers will accept it, however....we'll see.
>
> Why don't you do as most other APOP implementations; You add a special
> file with the POP passwords, and if the users' passwords are in that file
> they may use APOP otherwice they will have to use the normal USER/PASS
> authentication? If that file is only read/write able by root, you could
> add a suid command for the users to change password. Another possible
> method would be to have a dot file in their homedir with their pop
> password even though this would be slightly more insecure.
>
> /Sebastian
>
>

Hey, that is a good idea. However, I think that no matter what I do the
user still has to do something extra. What I have now is a command that
shows them their encrypted Unix ID (I called the command "apop_password")
and they can log in to the server, run that command and then set their
password to that encrypted password on their Eudora password with APOP
enabled and it seems to work fine (at least from Win95 Eudora 3.0...MAC
Eudora 3.0 seems to be having some kind of problem with APOP).

David Wayne Summers "Linux: The choice of a GNU generation."
david@summersoft.fay.ar.us PGP Public Key available on request.
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8

On Mon, 17 Mar 1997, Sebastian Andersson wrote:

> Date: Mon, 17 Mar 1997 09:57:16 +0100 (MET)
> From: Sebastian Andersson <sa@hogia.net>
> To: David Summers <david@summersoft.fay.ar.us>
> Subject: Re: QMAIL + (APOP)/IMAP/POP3
>
>
>
> On Mon, 17 Mar 1997, David Summers wrote:
>
> > Hey, that is a good idea. However, I think that no matter what I do the
> > user still has to do something extra. What I have now is a command that
> > shows them their encrypted Unix ID (I called the command "apop_password")
> > and they can log in to the server, run that command and then set their
> > password to that encrypted password on their Eudora password with APOP
> > enabled and it seems to work fine (at least from Win95 Eudora 3.0...MAC
> > Eudora 3.0 seems to be having some kind of problem with APOP).
> >
>
> But unless one uses shadow passwords everyone on the server can read
> all other users mail.
>
> /Sebastian
>
>

Woops! An EXCELLANT point! OK, forget that idea...back to the drawing
board. I'll probably re-implement it using a private .apop (or some other
file).

David Wayne Summers "Linux: The choice of a GNU generation."
david@summersoft.fay.ar.us PGP Public Key available on request.
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8

>
> Woops! An EXCELLANT point! OK, forget that idea...back to the drawing
> board. I'll probably re-implement it using a private .apop (or some other
> file).
>

is there a protocol limitation that says you can't get the client to
encrypt the password unix-style, and then use the result during negotiation?
but i suppose you don't have control of the client...

paul

On Mon, 17 Mar 1997, Paul Fox wrote:

> >
> > Woops! An EXCELLANT point! OK, forget that idea...back to the drawing
> > board. I'll probably re-implement it using a private .apop (or some other
> > file).
> >
>
> is there a protocol limitation that says you can't get the client to
> encrypt the password unix-style, and then use the result during negotiation?
> but i suppose you don't have control of the client...
>
> paul
>

Basically I think the standard says that the server and client have to
have a "shared secret". It really doesn't matter what it is just as long
as they both know what it is. I was trying to come up with a way that the
user wouldn't have to "know anything extra" but haven't been able to
figure out any way to do that.

--
"Never under-estimate the bandwidth of a station-wagon
David Summers full of tapes, hurtling down the highway."
dws@engr.uark.edu - Tanenbaum, "Computer Networks"

David Summers <david@summersoft.fay.ar.us> writes:
| Woops! An EXCELLANT point! OK, forget that idea...back to the drawing
| board. I'll probably re-implement it using a private .apop (or some other
| file).

All this grinding labor to beat apop into submission... kerberos would
be much more appropriate.

On Mon, 17 Mar 1997, Scott Schwartz wrote:

> David Summers <david@summersoft.fay.ar.us> writes:
> | Woops! An EXCELLANT point! OK, forget that idea...back to the drawing
> | board. I'll probably re-implement it using a private .apop (or some other
> | file).
>
> All this grinding labor to beat apop into submission... kerberos would
> be much more appropriate.
>
anything which runs a pre-authenticaed session would work.

given an unmodified client (eg Pegasus Mail for Windows) how would one
make use of Kerberos?

RjL
+----------------------------+
| richard@illuin.demon.co.uk | Aut viam inveniam aut faciam
+----------------------------+

Richard Letts <richard@illuin.demon.co.uk> writes:
| anything which runs a pre-authenticaed session would work.

Maybe yes, maybe no, details are everything. Kerberos is a fully
realized solution; no new kludges required.

| given an unmodified client (eg Pegasus Mail for Windows) how would one
| make use of Kerberos?

If that software is inadequate, don't use it. That's the same logic
that leads us to run qmail instead of sendmail.

On Mon, 17 Mar 1997, Scott Schwartz wrote:
> If that software is inadequate, don't use it. That's the same logic
> that leads us to run qmail instead of sendmail.

That's obviously overlooking many factors in your average commercial
venture. Things like the cost of changing all of your software,
installing all of the new software, and getting everyone used to the new
software.

Those and other complicating factors make that approach impractical in the
short term.

-Peter

On Mon, 17 Mar 1997, Scott Schwartz wrote:

> Richard Letts <richard@illuin.demon.co.uk> writes:
> | anything which runs a pre-authenticaed session would work.
> Maybe yes, maybe no, details are everything. Kerberos is a fully
> realized solution; no new kludges required.
no, it's not a fully realised solution, it requires an infrastructure and
modified clients. one could argue that Novell's NDS provides a fully
realized solution.

> | given an unmodified client (eg Pegasus Mail for Windows) how would one
> | make use of Kerberos?
>
> If that software is inadequate, don't use it. That's the same logic
> that leads us to run qmail instead of sendmail.

please suggest a windows / windows95 pop3 client capable of making use of
kerberos authentication.

The difficulty in replacing sendmail on a number of machines is (in my
case) three orders of magnitude smaller than replacing the client on user
PC's.

RjL
+----------------------------+
| richard@illuin.demon.co.uk | Aut viam inveniam aut faciam
+----------------------------+

"Peter C. Norton" <spacey@avsi.com> writes:
| That's obviously overlooking many factors in your average commercial
| venture. Things like the cost of changing all of your software,
| installing all of the new software, and getting everyone used to the new
| software.

Users are used to having software change out from under them.
Microsoft, Sun, and other vendors force you to do it all the time, with
less advantage to the users.

This is important. Take the long view. Do the right thing.

On Mon, 17 Mar 1997, Scott Schwartz wrote:

> "Peter C. Norton" <spacey@avsi.com> writes:
> | That's obviously overlooking many factors in your average commercial
> | venture. Things like the cost of changing all of your software,
> | installing all of the new software, and getting everyone used to the new
> | software.
>
> Users are used to having software change out from under them.
> Microsoft, Sun, and other vendors force you to do it all the time, with
> less advantage to the users.
>
> This is important. Take the long view. Do the right thing.

Ok. I've been converted. I'm ready to do the right thing. Please point
me to where I can pick up my Kerberos-capable Windows and Macintosh e-mail
clients.

Many thanks,

Patrick Kane
The Electronic Newsstand
<modus@enews.com>

On Mon, 17 Mar 1997, Scott Schwartz wrote:
> "Peter C. Norton" <spacey@avsi.com> writes:
> | That's obviously overlooking many factors in your average commercial
> | venture. Things like the cost of changing all of your software,
> | installing all of the new software, and getting everyone used to the new
> | software.
> Users are used to having software change out from under them.
> Microsoft, Sun, and other vendors force you to do it all the time, with
> less advantage to the users.
> This is important. Take the long view. Do the right thing.

You've addressed one out of the prior 3 factors that could impede the
decision to change a piece of software over to a competing product, and
not completely at that. The time+$$ cost of installation and $$ cost of
software and it's learning curve only make sense when there is a
proportional benifit.

If a product (like pegasus mail) supports APOP (which I think it does),
but not kerberos, and an office doesn't use kerberos in any other context,
then the right thing in that case is probably to go with APOP instead of
spending a lot of time and money changing the office to a new mail client,
and setting up and maintaining an entire kerberos infrastructure just for
that.

OTOH, If there are other uses in your office for kerberos, and it's a long
term use, then it's worth while.

Anyway, please remember that not everyone's situation is exactly what
yours is. I think these decisions can go both ways. Depending on
circumstances both ways can be the right way. My initial statement
(quoted above) was trying to make that point, and not for any other
reason.

-Peter

On Mon, 17 Mar 1997, Patrick Michael Kane wrote:
> Ok. I've been converted. I'm ready to do the right thing. Please point
> me to where I can pick up my Kerberos-capable Windows and Macintosh e-mail
> clients.
:)

For the curious, eudora has a kerberos option in it's configuration. I
don't know if it works w/ kerberos 5 (aka the hard to break kerberos).
Aren't there a lot of timing attacks on kerb 4?

-Peter

At 12:56 AM 3/18/97 +0000, you wrote:
>On Mon, 17 Mar 1997, Scott Schwartz wrote:

>please suggest a windows / windows95 pop3 client capable of making use of
>kerberos authentication.

Eudora has that ability, and I believe Eudora Light can even use Kerberos,
and it's free (at least for single users... not sure about using it
commercially...)

>The difficulty in replacing sendmail on a number of machines is (in my
>case) three orders of magnitude smaller than replacing the client on user
>PC's.

On this we certainly concur! I've had to deal with many clients of all
computer-knowledge ranges... and very, very few like change. Their favorite
saying is "it always worked before... why do we have to change now???"

[[ I'm not including the "get it working *now*!" That's a given... ]]

Hope this helps,
Roger "Merch" Merchberger

--
Roger Merchberger | Everyone complained to me to change my .sig,
Programmer, NorthernWay | but no-one could recommend something better.
zmerch@northernway.net | So you'll have to put up with this *junk*
| until I find some new wisdom to share.