I'm currently working on "Auth.py" to try to make it more of a general solution to authentication than it currently is. I think David Guerizec planned to have it eventually replace the authentication parts of tmda-cgi, tmda-ofmipd, and be used in tmda-gui / tmda-manager - all in the name of reducing code duplication.
In the CVS right now is a very slightly altered version of his original Auth.py that somewhat works with the CVS version of tmda-cgi. I believe the checkpassword interface works, and I've tested remote authentication with IMAP, but that's all I know that works for sure. After failing thus far to contact David about it, I thought I'd post to this list about the direction this bit of code should go: 1) Is this still a useful thing - one set of functions that just do authentication? 2) Should I make it into a class? There are some state variables and things that make it look like information hiding would be a good thing. Then again, it is mostly just utility functions anyway. 3) What default values are reasonable? Should the default authentication be from the file /etc/tmda-pwd or something like that? Should there be a default authentication, or should it be required that the calling program set that all up? (since they probably will anyway) 4) What features are necessary? What are useful? Here's the list I have so far of things I think it should do: - (If a class) Initialize the object with or without choosing the authentication method - Choose/change the authentication method (currently possible but not neatly encapsulated) - Frontend: Check a plaintext password (currently possible, needs some prettying up) - Frontend: Check a cram-md5 digest given the digest and the original ticket. (Can only be done if there is a plaintext password, I think) (currently not supported) - Backend: Check against a tmda-ofmipd-style username:cleartext file (must be mode 400 or 600) (Necessary to support cram-md5 authentication) (Not implemented yet) - Backend: Check against a tmda-cgi-style username:crypt-password file (may be any mode) (Not implemented yet) - Backend: Use checkpassword authentication (implemented and seems to work) - Backend: Use remote authentication (implemented and seems to work with imap, other protocols not tested yet) Here's the list of what it might be able to do: - Setup the HOME and USER environment variables for a user (should support virtual users) (Not really implemented yet) - Set the userid of the current process to that of a user (should support virtual users) (May be implemented for regular users) - Fork off, set the userid, and run a program as a user (Partially implemented, I think) 4) Since tmda-ofmipd does all these things and more so well, I'm transferring a lot of that code into Auth.py, and so I have one question about an undocumented feature in tmda-ofmipd: What is /etc/ipauthmapfile for in tmda-ofmipd? I understand how it works, mapping the host and port automatically based on the local address, but not what it's for. Or should I assume that tmda-ofmipd would take care of this ipauth mapping jazz and just past the final uri to Auth.py? 5) From what little I know of cram-md5 authentication and what little I've learned from rfc 2195, is there some way to store some intermediate step towards the HMAC digest without leaving the plaintext password on disk? For example, could this happen: User or admin generates the password on disk (using some to-be-designed password generator) and gives it the username, plaintext password, and file to append/change. generator program makes an hmac object with "hmac_obj = hmac.HMAC(password)" generator program makes an encrypted password with "crypt_pw = crypt.crypt(password, salt)" generaton puts the following line into the password file: username:crypt_pw:hmac_obj where hmac_obj is the "pickled" hmac_obj which can some time in the future be used as follows after being re-loaded from the file: newhexdigest = hmac_obj.update(ticket).hexdigest() Except that as of right now md5 objects and therefore hmac objects are not pickle-able. Would this add anything except complexity? Is there another way to do this? Or are cleartext passwords here to stay as long as CRAM-MD5 authentication lives? I think that's all I've got for now, thanks for your time! -- Jim Ramsay [EMAIL PROTECTED] PGP Key ID: 0xBE28F488 _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
