>RFC1460 describes the POP3 protocol, including an APOP message for
>avoiding the exchange of cleartext passwords. Basically, the server
>sends the client a string guaranteed to never be repeated. The client
>produces an MD5 hash on the combination of this string, the user name,
>and a shared secret (password) and sends that to the server. The server
>produces the same hash on the same values and sees if the hashes match.
>
>Comments:
>
>1. I don't know how widely this is implemented, if at all, in both
> clients and server.
Unfortunately I don't remember where I got them, but there is a set
of patches for the Berkely popper that enable apop for it.
The login banner changes to look like:
+OK UCB Pop server (version 1.831beta) at <19379 .
792969470 @
intercon> starting
The password is stored in a file - /etc/poppasswd by default - in a plaintext
user:password
format. The patch comments opine that this 0600 mode file, using a different
password from the users login password, presents /less/ of a hole than sending
the login password in cleartext.
>2. Wouldn't it preclude the use of the user's login password (on Unix)?
> The server cannot produce the unencrypted password from the
> /etc/passwd file since it is not stored therein, only a one-way hash of
> the password. And the client could not use the hashed password in
> producing it's MD5 hash, since it wouldn't know what salt value was used
> by the server system's passwd system. (Right??)
>
The point, as I understand it, is to use a DIFFERENT password from the login
password.
Hm. Let's see if I can find the readme...
Here it is...
------
The format of the file /etc/poppasswd is
username:passwd
Where username occurs in the password file with a non-null password
entry, and passwd is a string of up to 8 characters WHICH IS NOT
THE USERS UNIX PASSWORD. The popper has no actual length restriction
on the password, but it appears the APOP implementation in Eudora only
allows up to 8 characters.
The file /etc/poppasswd should be owned by root,staff and be read,write
by root only. By using a different secret than the UNIX login password
you limit the exposure of a "password file in the clear" to POP services
only. The paranoid would arrange that the dump of the root filesystem
that /etc/poppasswd resides on be encrypted.
You use a P instead of a p in the UNIX Navs plugin for Eudora to get it
to use an independent password for the POP authentication when logging
in over a serial line.
------
As for client support, there's Eudora, which has the broken length limit,
and our own TCP/Connect II for Macintosh has an APOP enabler with no such
limit. I'm not aware of others, but I don't actually track the market...it's
not my job...:)
JB
SysAdmin,
InterCon Systems Corp.
Not, of course, speaking for them...just about them...
|
|
