APOP for UNIX, the Mycal Way


Code and patches are here!


Disclaimer

This Document is (c)1997 by Mycal Labs. More to come...

Introduction

Maybe I worry to much, but it bothers me that in this day and age that unencrypted passwords are so freely squirted around on the internet. I have a server that has a few accounts on it that are accessed from all over the country through various ISP's, and during these accesses there it is possible that unscruplious people working at one of these ISP's or their upstream provider could sniff the line and have the keys to enter my system. At least I have a chance against a hacker attacking my system with little inside knowledge, but give him a set of keys and it makes his job much easier.

Even in a closed system, like behind a firewall, secure passwords are important. Most MIS managers won't admit this, but 97% of the security problem is internal. Employees hacking systems, snooing in other empoyees mail, and stealing others ideas to use as their own. A rouge employee with a packet monitor on his laptop can compromize most companies internal networks.

In the search for protection I decided to secure mail first. Pop mail and FTP (when not using unix based FTP programs) are the easyest passwords to snatch on a network, but with my userbase I get 200 pop requests for every FTP request.

I noticed that Eudora supported kerberos and APOP so I searched and searched for a Unix POP server with support for one of these protocols and couldn't find much. I did find lots of servers for non Unix operating systems that supported APOP, but not for Unix. Hmmmm, I wondered why.

The rest of this document is how I solved my APOP problem. It is usable under any Unix operating system, but I have it implemented under Redhat 4.2 Linux.

APOP Problems in UNIX

"I wonderd why so little support for UNIX machines."
The major problem with APOP is that it is sparcly supported in the UNIX world. It seems like every version of POP3 for Windows NT or OS/2 supports APOP, so I wonderd why so little support for UNIX machines.

The answer is that UNIX machines don't know the users password, they know the encrypted strings, but not the real passwords. APOP encypts the plain text passwords and a timestamp givin to it by the POP server with MD5 and sends the 32 byte MD5 Digest to the pop server for validation. Since a UNIX machine doesn't know the plain text password, it cannot validate the the user.

I figured all this out when I downloaded a copy of cucipop that claimed to support APOP. It did, in a way, but it was not 100% compleat. After a few hours of hacking I patched it to support my solution.

My Solution

After I spent all this time digging in the cucipop code and reading RFC1939 I figured out why APOP didn't work well on a UNIX machine, I was bummed and still needed a solution. It then struck me to use the encrypted string from my shadowed password file as my POP password in Eudora client, selected APOP authentication and volia it worked.

It wasn't the ultra clean solution I was looking for, but it worked, and my passwords were not travling plain text across the internet. Actually this method is more secure than traditional APOP solutions. If one of my users gets his laptop hacked and his password is tored in his mail program, all the thief gets is the keys to a pop box, the encrypted string won't get him shell or FTP access, and would be difficult to hack if password selection was wise. FTP.

"Actually this method is more secure than traditional APOP solutions."

The Next Level

The above solution is a good one, but requires extra work by the sysadmin to manage. I decided that I'd take this solution to the next level and build a set of APOP management utilities to let a user manage his own APOP password strings, and build added security so that a unix password cracker would be useless in attacking a captured APOP password string to get the real password.

To do this the APOP server and the APOP management utilities need to share a secret, this can be in a file that only the APOP server and management utilities can access. Both programs will generate another MD5 digest using the Unix Crypted Password string of the user and the shared secret. This Digest will be used as the APOP password by the user to pop his mail.

Final Observations

It should be quite simple to add APOP support for the Mycal Method. When I have time I'll try to patch another pop server and document the steps I took.

Also since this may not be the solution for everyone I'm going to look into kerberos and other secure autentication methods.

My Patches and Code

  • getapop V1.0- APOP password utilities.
  • cucipop-1.14 patch to do apop the mycal way.

    (c)1997 Mycal Labs, All Rights Reserved.