Good morning. I have replied inline. My responses may be very detailed. This is due to your questions not providing any context in regards to your client/server application. If I had more details on that I could provide one simple answer of how to proceed. ________________________________________ From: pam-list-bounces@xxxxxxxxxx [pam-list-bounces@xxxxxxxxxx] on behalf of Claude Brisson [claude@xxxxxxxxxxx] Sent: Friday, September 12, 2014 4:15 AM To: pam-list@xxxxxxxxxx Subject: PAM module for client/server application Hi. Among the forest of all available PAM modules in standard linux distros, I was unable to identify the one I should use to fulfill my need: I'm developing a client/server application that needs authentication. I'd like this authentication to be handled by PAM. For instance, if I want to rely on linux shadow passwords for existing accounts, I'll have my server belong to the "shadow" group and use the "auth-common" module. So far, so good. Typically you should not have any user accounts assigned to the 'shadow' group. PAM modules have access to the getpwnam functions as they are executed within the root user context. For help in manually accessing the local password database please reference the man pages for getpwnam (http://linux.die.net/man/3/getpwnam). But I cannot use SSL or TLS for the client/server protocol, so I have to encrypt the user password. In such situations, I'd usually have the server send a one-time challenge, and the client respond sha1(pass+challenge). Or, if the pass is itself encrypted in the database, let say by some hash() function, the client would answer sha1(hash(pass)+challenge), and the server, knowing the real pass, can check authentication. Technically you should use a one time pad cipher for the most secure configuration. The problem with this is that it requires both ends have previously established a shared secret while using a symmetric encryption cipher such as AES in CTX mode. Using an asymmetric encryption cipher such as RSA &/or DH (diffie hellman) requires a key exchange which can lead to an insecure communication channel if an attacker is monitoring the initial key exchange. If this is what you wish to use I would suggest using the OpenSSL API to establish a secure communications channel for the key exchange. For more information using their API please refer to the 'Usage & Programming' section http://wiki.openssl.org/index.php/Main_Page#Usage_and_Programming. Or if you need more information regarding the various principals of using encryption for key exchanges etc the 'Concepts & Theory' sections can provide that information. http://wiki.openssl.org/index.php/Main_Page#Usage_and_Programming. If you are unable to use SSL/TLS perhaps you should implement the Kerberos PAM module (pam_krb5) which implements your above suggested solution in a cryptographically secure manner. My understanding is that I *have* to give the provided password as is to PAM, because I don't have any mean of telling PAM *how* it should be compared to the stored password. Put it in another way, I cannot tell PAM "here is my <challenge>, the user provided <sha1(hash(pass)+challenge)>, please check that". The pam library you will link against during compile has methods for accessing the user supplied credentials. For more information on how to use the PAM API please review the developers guide at http://www.linux-pam.org/Linux-PAM-html/Linux-PAM_ADG.html And so, it means the only solution is to encrypt the password with a reversible encryption function and not with a hash. Am I right? Technically correct. However due to using an insecure communications channel (I.E. no TLS/SSL wrapping the payload of the communication stream in a secure RSA/DH key exchange) a MITM (man in the middle) scenario will present itself. Because I am unsure of your actual problem. I recommend use of the pam_krb5 module for authentication as a 'roll your own crypto solution' will only serve to create a liability for your password handling in the future. Using libraries that have been developed specifically for these problems (see pam_krb5, pam_ldap, etc). Hope this helps. Thanks, Claude _______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list _______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
