Date: Sat, 23 Mar 2013 21:51:53 -0700 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: Doug Hardie <bc979@lafn.org> Cc: "freebsd-questions@freebsd.org List" <freebsd-questions@freebsd.org> Subject: Re: Client Authentication Message-ID: <CAOgwaMvu%2BOC4PiPfNNwoj7aB%2B631Nt_=SwjFG9y89%2BavB6Mp9Q@mail.gmail.com> In-Reply-To: <B2DC7342-9F1A-489A-94F0-49802B1E5DF6@lafn.org> References: <B2DC7342-9F1A-489A-94F0-49802B1E5DF6@lafn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 23, 2013 at 9:22 PM, Doug Hardie <bc979@lafn.org> wrote: > I am not sure this is the best place to ask this, but I didn't see any > other maillists that seemed more appropriate. > > Basically, my outgoing mail server is being systematically attacked to try > passwords looking for one that works. When they do find one, we get > inundated by spam sent through that account throughout the world. The > situation is such that most of our users are older and their computer is a > hand-me-down so they can talk to their grandchildren. Passwords are a > great inconvenience for them and create numerous problems with remembering > them even when they are simple. Unfortunately, most of them are quite easy > to guess. > > Telling users to use more appropriate passwords is a complete waste of my > time. Its never going to make any changes as they probably would not > remember any other password (or where they wrote down the password). This > situation requires a technical solution. > > I have been investigating the use of client authentication through SSL. > DoD uses this approach by having the certificates on an ID card and a card > reader on each computer. We don't have the money to use that approach no > could we every get our users to spring for that. I was hoping to figure > out a way to put the certificate on a flash drive or CD that the user would > carry. The approach we use has to also work for iPads, smart phones etc > that do not have an interface for a card reader. > > At this time, I have successfully configured a test for openssl client > authentication using a client certificate. There are a few issues > remaining. DoD uses a p12 format for their certificates. Many browsers > support that format. It encrypts the certificate and private key so they > are not easily obtained from the smart card. Openssl's s_client uses pem > certificates and the key has to be included in the certificate file. While > that is easily transported on CD or flash drive, the private key is in the > clear on the device. Thats not really viable. > > S_client works properly without a certificate when the certificate check > in the server is set to not fail if a certificate is not provided. This is > needed because we will never get all our users to use this approach at > home. They will still want to use passwords. Since the certificate > request is made before the connection information is available, there is no > easy way to request it only when needed. I have only been able to test > with the Safari browser and it does not handle the no certificate case > properly. I believe it is dropping the connection when the user does not > select a certificate. I still have to test the other browsers. > > There is an interesting aspect of openssl that the certificate it uses for > normal SSL authentication is not used for client authentication. There are > another completely different set of calls that have to be made to set the > certificate/key for use in validating the client certificates. Much of > this is only documented in existing code. > > With Safari you have to import the client's certificate into the keychain. > Then it works fine. Unfortunately, it doesn't go away when you are done > with it. Unlike the smart card which, when removed, removes the > certificate, the Safari certificate can continue to be used by anyone > afterwards. Hence, its not all that useful for authentication. One > approach I have heard about, but not investigated yet is to place the > keychain on the removable device. That would make it go away. However, > that approach would not work with any other browser or mail program. > > Any ideas/suggestions on this will be appreciated. Thanks, > > -- Doug > Using Static IP in the client side , and checking Static IP of the user may be a possibility : In that way , any message from another IP will not be accepted . If this is possible for your systems , it may be checked for usability . One difficulty is that each user should obtain a Static IP and can not connect to his/her ISP from another IP . Good side is that nobody can connect to ISP of the user from another IP : It supplies hardware security ( we are assuming that the user computer is not captured ) .. Thank you very much . Mehmet Erol Sanliturk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMvu%2BOC4PiPfNNwoj7aB%2B631Nt_=SwjFG9y89%2BavB6Mp9Q>