Re: Client Authentication
On Sat, Mar 23, 2013 at 09:22:07PM -0700, Doug Hardie 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 A little while back I wrote a system to do a simple Two Factor Authentication and dynamic manipulation of PF (Packet Filter) Tables. I created it to prevent brute-force attacks on the servers that I have exposed on the Internet. Users would carry around a flash drive that has an HTML file containing a message that is signed by your server (Alternatively, the HTML file can be saved/placed of frequently used devices). When users double-click that file, that message is verfified and the user is then prompted for his/her password. If the password is correct, then access from the user's IP is allowed to your server. The system is released as FOSS and is available at: http://taferno.sourceforge.net More info may be found at: http://taferno.com I don't know if it will work for you. But, you can try if you'd like. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd
Re: Client Authentication
On 27/03/2013 4:18 AM, Joseph Olatt wrote: Any ideas/suggestions on this will be appreciated. Thanks, -- Doug A little while back I wrote a system to do a simple Two Factor Authentication and dynamic manipulation of PF (Packet Filter) Tables. I created it to prevent brute-force attacks on the servers that I have exposed on the Internet. I'm happy to share a program I wrote which slows down the brute force attackers. It simply counts the SYN packets from a given IP and limits the rate per minute by dropping the packet if they are coming too fast. Uses ipfw divert sockets, so would work if you prefer ipfw over pf. If you have a known set of OK IP addresses, you can allow them in ipfw rules before the packets get passed through ratelimit. ratelimit usage: -p size maximum packet size (default: 16384 bytes) -d port divert port number (default: 1) -r rate rate at which 50% of packets are dropped (default: 4) -f rate rate at which 100% of packets are dropped (default: 8) -l secs number of seconds to sleep between syslog() calls (default: 30) -z path path of pidfile (default: /var/run/ratelimit.pid) -hthis message Have you looked at simply using a non-standard port? Danny ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On Tue, 26 Mar 2013 22:56:37 +0100, Daniel O'Callaghan da...@clari.net.au wrote: On 27/03/2013 4:18 AM, Joseph Olatt wrote: Any ideas/suggestions on this will be appreciated. Thanks, -- Doug A little while back I wrote a system to do a simple Two Factor Authentication and dynamic manipulation of PF (Packet Filter) Tables. I created it to prevent brute-force attacks on the servers that I have exposed on the Internet. I'm happy to share a program I wrote which slows down the brute force attackers. It simply counts the SYN packets from a given IP and limits the rate per minute by dropping the packet if they are coming too fast. Uses ipfw divert sockets, so would work if you prefer ipfw over pf. Me Me Me! ...ahem. I do prefer IPFW over PF and would very much like to try it out, so please do share. Regards, Michael ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On 27/03/2013 10:37 AM, Michael Ross wrote: I'm happy to share a program I wrote which slows down the brute force attackers. It simply counts the SYN packets from a given IP and limits the rate per minute by dropping the packet if they are coming too fast. Uses ipfw divert sockets, so would work if you prefer ipfw over pf. Me Me Me! ...ahem. I do prefer IPFW over PF and would very much like to try it out, so please do share. OK, here 'tis https://secure.clari.net.au/ratelimit2.tgz Danny ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On Wed, 27 Mar 2013 01:37:36 +0100, Daniel O'Callaghan da...@clari.net.au wrote: On 27/03/2013 10:37 AM, Michael Ross wrote: I'm happy to share a program I wrote which slows down the brute force attackers. It simply counts the SYN packets from a given IP and limits the rate per minute by dropping the packet if they are coming too fast. Uses ipfw divert sockets, so would work if you prefer ipfw over pf. Me Me Me! ...ahem. I do prefer IPFW over PF and would very much like to try it out, so please do share. OK, here 'tis https://secure.clari.net.au/ratelimit2.tgz Danny Thanks! I'd like to be able to change the time window: http://gurder.ross.cx/misc/ratelimit.patch Regards, Michael ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On 27/03/2013 12:59 PM, Michael Ross wrote: I'd like to be able to change the time window: http://gurder.ross.cx/misc/ratelimit.patch Neat. Thanks for that. Danny ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On Sat, Mar 23, 2013 at 10:16 PM, Doug Hardie bc...@lafn.org wrote: On 23 March 2013, at 21:51, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: 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 ) .. That is an interesting idea, but unfortunately our users tend to travel a lot and need to be able to access mail from anywhere. Also, static IPs can get quite expensive from some ISPs. Our users are pretty much on fixed incomes and any expense is a hardship for them. -- Doug The following steps may be another idea : Assume that you supply to your users a small login program prepared for them specifically ( since you are using SSH ) : Compile that program for each user with a special identifier for him/her and ship this program to your user and require that the login will be performed by this program . This program will send a very long code to your system with user password which is only known to you and to your user . Since external users will not know this code , they will not be able to login into their accounts by using only password . This will also easily identify fake login trials : It is very obvious that to estimate a very long code will require a large number of tries : If code fails , it means that login trial is from a fake user . If password fails , it may be allowed a fixed number of trials ( The banks are allowing only TWO failed passwords , on third , a new attempt can be made after 24 hours , in Turkey ) . This program may also additionally send computer signature to your system which is previously send to you on subscription computed by a program prepared by you . If the user changes / or uses a different computer , he/she should supply a signature of the computer . Here , important point is that , always you should verify that you are communicating the real user , not a faked user in behalf of the real user . For the stolen program/codes , prepare a new program and ship to the user . Another idea may be the following : Assume the user computer is NOT captured by a criminal bandit . On subscription , send to the user a square bar code printed on a card like credit card having a very long code specifically prepared for the user . On login , the user will show this card to the camera of the computer and will be transmitted to your system . In your system , it will be decoded , and it will be used to identify the user with his/her password . If this application is used , it may not be necessary to send the users a special login program prepared for each of them . Thank you very much . Mehmet ERol Sanliturk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On Sun, Mar 24, 2013 at 9:03 AM, CeDeROM cede...@tlen.pl wrote: Why don't you just use PKI for authentication (you can generate your own certificates)? You can easily upload keys/certificated to client machines (PC, Android, Apple, ...). That should work :-) You can additionally encrypt keys/vertificates with a easy to remember short PIN or password for increased security. I have seen this working with Aladdin eToken maybe there is a pure software solution :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On Sat, Mar 23, 2013 at 9:22 PM, Doug Hardie bc...@lafn.org wrote: 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. You might consider disabling external smtp auth service and using ssh tunnel to server to connect to mail. Also provide web based convenience service. It might be interesting to encrypt mail to the user's cloud service that operates in a gpg zone. I think this operation could be mostly transparent to the user, so kids and granpamas can use it without concern. -- Waitman Gobble San Jose California USA 510-830-7975 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On 24 March 2013, at 01:03, CeDeROM cede...@tlen.pl wrote: Why don't you just use PKI for authentication (you can generate your own certificates)? You can easily upload keys/certificated to client machines (PC, Android, Apple, ...). That should work :-) Thats exactly what I have been testing. Its easy in concept, but there are issues in the details. Once the certificate is loaded in a Mac and the password entered, its available for anyone to use thereafter. You actually have to remove the certificate from the keychain to disable it. Not a great approach for shared computers. Most users will not know how to remove it properly. I don't know about PCs yet though. In addition there are possible issues with mail clients. I have not tried them yet. It all depends if they can handle p12 format certificates. Pem format certificates must have the private key in plain format which renders them completely insecure. Then there still is the issue about Safari (at least) not handling the no certificate case properly. -- Doug ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On 23 March 2013, at 22:59, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: The following steps may be another idea : Assume that you supply to your users a small login program prepared for them specifically ( since you are using SSH ) : Compile that program for each user with a special identifier for him/her and ship this program to your user and require that the login will be performed by this program . This program will send a very long code to your system with user password which is only known to you and to your user . Since external users will not know this code , they will not be able to login into their accounts by using only password . This will also easily identify fake login trials : It is very obvious that to estimate a very long code will require a large number of tries : If code fails , it means that login trial is from a fake user . If password fails , it may be allowed a fixed number of trials ( The banks are allowing only TWO failed passwords , on third , a new attempt can be made after 24 hours , in Turkey ) . This program may also additionally send computer signature to your system which is previously send to you on subscription computed by a program prepared by you . If the user changes / or uses a different computer , he/she should supply a signature of the computer . Here , important point is that , always you should verify that you are communicating the real user , not a faked user in behalf of the real user . For the stolen program/codes , prepare a new program and ship to the user . Thats an interesting approach but becomes difficult to use when traveling as you have no idea what computer you will be able to use today until you get to it. Then you might have only a few minutes access to it before moving on. Another idea may be the following : Assume the user computer is NOT captured by a criminal bandit . On subscription , send to the user a square bar code printed on a card like credit card having a very long code specifically prepared for the user . On login , the user will show this card to the camera of the computer and will be transmitted to your system . In your system , it will be decoded , and it will be used to identify the user with his/her password . If this application is used , it may not be necessary to send the users a special login program prepared for each of them . This idea shows a lot of promise. I have to figure out how to tie it into mail, web etc. There is libqrencode for creating the QR images. I am downloading it now. -- Doug ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On Sun, 24 Mar 2013 01:16:33 -0700, Doug Hardie wrote: On 24 March 2013, at 01:03, CeDeROM cede...@tlen.pl wrote: Why don't you just use PKI for authentication (you can generate your own certificates)? You can easily upload keys/certificated to client machines (PC, Android, Apple, ...). That should work :-) Thats exactly what I have been testing. Its easy in concept, but there are issues in the details. Once the certificate is loaded in a Mac and the password entered, its available for anyone to use thereafter. You actually have to remove the certificate from the keychain to disable it. Not a great approach for shared computers. Wouldn't there be a possibility to combine key _and_ password? The key shouldn't have to be removed, but it should only work with a password (which again is kept individual to each user). The process has to be made more uncomfortable to be secure, i. e., the password should _not_ be stored, instead it _has_ to be entered every time the secure connection is to be used. If a different user gets his hands on a running session (in terms of user-separation or profiles on a particular machine), he won't be able to do anything with mail as he does not know the password, and the password will not be automatically provided for the sake of being less complicated. I don't know your particular end user machine settings, so this is just a broad suggestion. Many things in this idea depend on what software the client systems use, and how this software actually deals with security-related settings and procedures. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On 24 March 2013, at 01:10, Waitman Gobble gobble...@gmail.com wrote: You might consider disabling external smtp auth service and using ssh tunnel to server to connect to mail. Also provide web based convenience service. I am not convinced that a ssh tunnel is going to be easy for my users. We do provide a web based mail client, but I wouldn't describe it as convenient. I find it a pain in the neck, but so many users requested it that we provide it. It is password authenticated but so slow it will never be attacked with password guessing. It might be interesting to encrypt mail to the user's cloud service that operates in a gpg zone. I think this operation could be mostly transparent to the user, so kids and granpamas can use it without concern. This one I don't understand. Can you provide pointers to this type of service? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
Certificate + Password/PIN should be okay. You can maybe create a policy for the target system to enable a screensaver to block the screen after short period that will force user to enter his/hers password..? I know in theory all seems easy :-) :-) Good luck! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On 24 March 2013, at 01:22, Polytropon free...@edvax.de wrote: Wouldn't there be a possibility to combine key _and_ password? The key shouldn't have to be removed, but it should only work with a password (which again is kept individual to each user). The process has to be made more uncomfortable to be secure, i. e., the password should _not_ be stored, instead it _has_ to be entered every time the secure connection is to be used. If a different user gets his hands on a running session (in terms of user-separation or profiles on a particular machine), he won't be able to do anything with mail as he does not know the password, and the password will not be automatically provided for the sake of being less complicated. I don't know your particular end user machine settings, so this is just a broad suggestion. Many things in this idea depend on what software the client systems use, and how this software actually deals with security-related settings and procedures. The p12 format certificate includes the key and both are encrypted. This seems like the best distribution format. From what I have read most browsers can handle this distribution format since it is used in smart cards. However, on Safari, at least, when you import the certificate you have to enter the encryption key for the certificate and key. Then those are stored in the keychain (without any additional reference to that encryption key). They than can be used by anyone on that machine. It kind of defeats all the effort for security up to that point. DoD addresses this issue by somehow making the certificate not be imported into the keychain, but retained on the smart card only. Pulling the card from the reader eliminates any future use of it. Thats what I would like to achieve. -- Doug ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On Sun, Mar 24, 2013 at 1:21 AM, Doug Hardie bc...@lafn.org wrote: On 23 March 2013, at 22:59, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: The following steps may be another idea : Assume that you supply to your users a small login program prepared for them specifically ( since you are using SSH ) : Compile that program for each user with a special identifier for him/her and ship this program to your user and require that the login will be performed by this program . This program will send a very long code to your system with user password which is only known to you and to your user . Since external users will not know this code , they will not be able to login into their accounts by using only password . This will also easily identify fake login trials : It is very obvious that to estimate a very long code will require a large number of tries : If code fails , it means that login trial is from a fake user . If password fails , it may be allowed a fixed number of trials ( The banks are allowing only TWO failed passwords , on third , a new attempt can be made after 24 hours , in Turkey ) . This program may also additionally send computer signature to your system which is previously send to you on subscription computed by a program prepared by you . If the user changes / or uses a different computer , he/she should supply a signature of the computer . Here , important point is that , always you should verify that you are communicating the real user , not a faked user in behalf of the real user . For the stolen program/codes , prepare a new program and ship to the user . Thats an interesting approach but becomes difficult to use when traveling as you have no idea what computer you will be able to use today until you get to it. Then you might have only a few minutes access to it before moving on. Another idea may be the following : Assume the user computer is NOT captured by a criminal bandit . On subscription , send to the user a square bar code printed on a card like credit card having a very long code specifically prepared for the user . On login , the user will show this card to the camera of the computer and will be transmitted to your system . In your system , it will be decoded , and it will be used to identify the user with his/her password . If this application is used , it may not be necessary to send the users a special login program prepared for each of them . This idea shows a lot of promise. I have to figure out how to tie it into mail, web etc. There is libqrencode for creating the QR images. I am downloading it now. -- Doug A single method may not be so much useful for ALL the users . You may design a part for mostly static users . For traveling persons , by using relevant information in your system , you may use a approximate solution : QR code , password , computer signature : If two of them is correct , and in user profile there is an information that the user travels frequently , you may assume his/her login is correct . Another point may be that the user inform your system that he will travel between dates ( if foreing countries are involved , he may specify them ) . By using such information , it may be possible to identify users correctly as much as possible . This requires a good user profile definition in your system , and temporary exception which these exceptions should ALWAYS be obtained from fully verified login to prevent fake changes . As an example of bank robbery : A criminal , applying to a user GSM company instead of another person to be robbed by saying that My GSM device has been stolen . Please cancel it . Give a new GSM chip and number . After getting the new GSM number , the criminal is applying to bank for request Change my GSM number . instead of another person to be robbed . During money transfer of person to be robbed , the bank is sending a GSM message to the person , but diverted to criminal to get authorization . Person is giving authorization . As a result : Money is stolen . Rest is not important . The real person should go to court to prove that his/her money is stolen : Such a trial is taking almost five years . This means that security measures / steps should be designed with extremely carefully . All over the world , there a large millions of personal computers captured by criminals and are used for crime performance with the responsibility being on the real owner of the computer . For your users , some of them may obtain or have static IP numbers . Therefore , it is not necessary completely discard such an alternative . By using most secure method which can be implemented for the suitable users to least secure methods have been implemented persons with difficulty may be applied . For least secure methods , some statistical measures may be implemented : For example , average daily number of logins , average number of messages ,
Re: Client Authentication
At 11:22 PM 3/23/2013, you 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. brute force attacks are easily blocked with pf's connection rate-limiting. Because our mail users are not world travellers, we use PF to block sending IPs by country. Any IP that TCP connects x times in y minutes to your mail server gets blocked for z hours. Cracked passwords on our mail users seem to be stolen by infections or phished rather than obtained by brute force. Our sender rate-limiting has three levels Our outbound server (postfix + postfwd) has per-sender rate limiting, which has totally stopped the really high volume password cracks. We have 3 levels of rate limiting. 1. 2000 msgs limit for every sender. We chose 2000 by identifying a handful of legit habitual senders of up to 1500 msgs, who are whitelisted from rate-limiting for the following levels. 2. 700 msgs limit for senders who habitually send up to 500 msgs, who are whitelisted from the following limit. 3 50 msgs limit for all senders who are not whitelisted above. Rate limiting causes the msgs to be held, not discarded or rejected, with an alert msg to the mail admin, who then inspects the held msgs for releasing or deleting. All the cert and PIN stuff appears to be theoretical suggestions not based on experience, since while effective, it would be a practical nightmare of training and maintenance. Len ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On 24/03/2013 05:22, Doug Hardie wrote: Basically, my outgoing mail server is being systematically attacked to try passwords looking for one that works. Have you investigated to identify where these attacks originate from? Even if the IP is not fixed, they often belong to ranges assigned to a particular country or even a particular ISP. AFAIK best practice is to use port 25 for relaying mail between the servers, hence your server should only allow incomming mail on this port. This does not require authentication. Users should connect to port 587 on your server to send mail. This ofcourse requires authentication. If your users are not mobile, then you can simply block port 587 for external connections. Even if you have mobile users you can likely make some safe assumptions about where they will connect from, for example only national connections. 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. So, I assume that each user has a PC or laptop for personal use only? Do you need mail passwords to be the same as computer or network passwords? If not then help your users choose a strong mail password and enter it in the mail client's password manager. Writing down a password can actually be a better solution than bad passwords. If people have a private PC at home, it may even be acceptable to stick a post-it to the screen. Consider implementing a password policy that is enforced by technical means, requireing regular change and strength test before a new password is accepted. You may get heaps of user complaints with this though. But I think that users aversion for good passwords is that they have no idea of how to pick one that is easy to remember yet hard to guess, and that they may have to authenticate many times with many different passwords throughout the day. This situation requires a technical solution. I have been investigating the use of client authentication through SSL. With certificates you will likely encounter user problems as with passwords: You can install the certificates in the users keychain, with or without password protection or protected by the system password. This may actually be OK if that requires physical access to the user's computer. Or you can use some card reader as you mention, but if users have problem managing a piece of paper with a password, how will they do with a card? You will have to deal with lost cards in stead of forgotten passwords. From the description of your users I don't think this is a solution. In either case, whenever a certificate expire you will have to update it and help install the new certificate, and it becomes a hazle if the users gets a new computer. Any ideas/suggestions on this will be appreciated. Thanks, I think, given user's abilities the best option is use port 587 for authenticated outgoing SMTP with STARTTLS and a server side certificate. Restrict external access to port 587. Use mail client's password manager to store mail password and help users choose a strong password which will only be used once. Or, you can make away with the mail client and offer a web interface. Then mail can only be relayed for connections from localhost. BR, Erik ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
Doug Hardie bc...@lafn.org writes: That is an interesting idea, but unfortunately our users tend to travel a lot and need to be able to access mail from anywhere. Also, static IPs can get quite expensive from some ISPs. Our users are pretty much on fixed incomes and any expense is a hardship for them. I've been thinking about setting up certificates for pretty much the same reason, but I haven't gotten around to it yet. My standing impression is that the setup is mostly specific to the mail server, which in my case is currently dovecot. Regardless of what else you do, there are some defensive things you could do to take some of the pressure off. They won't be a solution, but they might make your life easier while you work on a solution. Port knocking would make it harder for the attackers to get through to try passwords, and it's fairly easy to install on any particular type of client. With the variety of clients you have to deal with, the cumulative effort may be overwhelming, but it's at least worth a thought. Another thing to try would be temporarily blocking any IP address that tries several different user names in a short period of time. Again, these kinds of things won't solve your problem, but they may reduce the intensity of the attack. Good luck. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
Doug Hardie wrote: 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. How such spam is injected into your mail relay - via SMTP? most of our users are older and their computer is a hand-me-down so they can talk to their grandchildren. our users tend to travel a lot and need to be able to access mail from anywhere. I bet that most of your users use Windows, many are clueless. So, many will click a link in a letter from a known sender if the letter contains nothing more than a link and the sender's correct signature, possibly with a correct sender name or a few very generic words added in Subject or body. Links in such spam lead to drive-by exploit kits such as Blackhole which silently (without user consent) install password-stealing trojans such as ZeuS or SpyEye in user's Windows. These trojans also are stealing FTP passwords (many webmasters use Windows too), it's how the felons make pages they link to (on legitimate websites), so content-filtering of such spam fails. Stolen yahoo, AOL, MSN webmail passwords are used for sending such spam via the webmail interface (with correct hostname, SPF, DKIM) to addresses harvested from the user's webmail interface's address book and Sent and Inbox folders. Also, some of your users will yield to phishing. Strong (long, complicate, unique) passwords are stolen with Windows trojans and phishing as easily as weak ones. You can block brute-force password guessing, but you cannot prevent password stealing by Windows trojans and phishing. Unfortunately, you cannot force your users to use FreeBSD or some other free operating system instead of Windows. But travelling users do need to send mail via SMTP. Passwords are stolen along with username, relay hostname and port. Second factor authentication for SMTP is more difficult in practice than for HTTP. So, you need to block _using_ stolen passwords by spammers. My implementation is for Exim (instead of Postfix or sendmail): https://github.com/Exim/exim/wiki/BlockCracking It also blocks brute-force password guessing via SMTP, but that's a side benefit. Lena ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On Sat, 23 Mar 2013, Doug Hardie wrote: On 23 March 2013, at 21:51, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: 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 ) .. That is an interesting idea, but unfortunately our users tend to travel a lot and need to be able to access mail from anywhere. Also, static IPs can get quite expensive from some ISPs. Our users are pretty much on fixed incomes and any expense is a hardship for them. Can you filter outgoing mail with Spamassassin? How about refusing to relay mail from addresses in a good DNSBL? Do you rate-limit outgoing mail? Can you just refuse to relay mail from other continents, using a geolocation service? daniel feenberg -- Doug ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On Sun, Mar 24, 2013 at 1:25 AM, Doug Hardie bc...@lafn.org wrote: On 24 March 2013, at 01:10, Waitman Gobble gobble...@gmail.com wrote: You might consider disabling external smtp auth service and using ssh tunnel to server to connect to mail. Also provide web based convenience service. I am not convinced that a ssh tunnel is going to be easy for my users. We do provide a web based mail client, but I wouldn't describe it as convenient. I find it a pain in the neck, but so many users requested it that we provide it. It is password authenticated but so slow it will never be attacked with password guessing. One idea is to run a different server process on 25 which does not do SMTP AUTH,, then run SMTP AUTH on 465 or 587. I don't really see a reason to advertise SMTP AUTH on 25, for some reason all mail servers seem to do AUTH on all ports or none. Maybe there is a way to configure SMTP AUTH only on certain ports, one way I can think of is to run two processes with two configs. If some people are specifically attacking your service this may not be optimal, but if it's script kiddies scanning servers on port 25 this might discourage them. Another thought is to modify the SMTP server to allow one or two failed attempts then lock the account. IRL people set up their password into their email program and don't type it in all the time, or in the case of web mail they make their browser remember it. There isn't a good reason I can think of to allow 100 failed SMTP AUTH attempts. This concept would have to be tweaked a bit to balance customer service demand. You could also use the age of the account to determine the number of failed attempts, newer accounts might get 10 failed attempts, for example. Or you could disable SMTP auth altogether and make a little program that sets up a tunnel. Here's an ssh library that's BSD licensed http://www.libssh2.org/examples/tcpip-forward.html I think you can decide how much user intervention is needed for port forwarding. IT could be something like the user has to have the service installed on their machine, or it's a 'click for email' type thing. A little program that sets up the tunnel behind the scenes. It takes a day or two of front end programming but might be a good solution that works on unix/mac/linux/ms machines. You can have your SMTP AUTH service listening only on localhost. Handheld devices might become a challenge. It might be interesting to encrypt mail to the user's cloud service that operates in a gpg zone. I think this operation could be mostly transparent to the user, so kids and granpamas can use it without concern. This one I don't understand. Can you provide pointers to this type of service? Sorry I don't have any pointers, it was an idea last night. The concept is that users have 'cloud' accounts, email is encrypted to their account, perhaps (off the top of my head) in a fashion similar to the way friendica works.(it's not working with cloud systems, but it encrypts information to individual users, this could be analyzed for ideas for a cloud based system). This kind of solution might take a week of programming to set up, so it's more work on the front end. If you have some archival requirement or need to parse/key or otherwise analyze messages, in that scenario you would have to copy the message I think. -- Waitman Gobble San Jose California USA 510-830-7975 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
How about refusing to relay mail from addresses in a good DNSBL? Bad idea. Legitimate users connecting from dynamic IP-addresses is normal. DNSBLs list a dynamic IP-address permanently or for long time after a zombied Windows spewed spam from it. Some DNSBLs warn about that explicitly, for example: http://www.spamhaus.org/zen/ | Caution: Because ZEN includes the XBL and PBL lists, do not use ZEN | on smarthosts or SMTP AUTH outbound servers for your own customers | (or you risk blocking your own customers). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On 24/03/2013 17:50, Waitman Gobble wrote: On Sun, Mar 24, 2013 at 1:25 AM, Doug Hardie bc...@lafn.org wrote: One idea is to run a different server process on 25 which does not do SMTP AUTH,, then run SMTP AUTH on 465 or 587. I don't really see a reason to advertise SMTP AUTH on 25, for some reason all mail servers seem to do AUTH on all ports or none. Maybe there is a way to configure SMTP AUTH only on certain ports, one way I can think of is to run two processes with two configs. Port 25 should be open for external connections and allow only local delivery. 465 is STMPS and should be configured as 25 but with SSL, this is really only useful if you have a certificate issued by a trusted CA as other servers will otherwise reject your certificate as untrusted. Port 587 is for message submission, see RFC 2476, you can configure it with TLS (serverside) and it should only advertise STARTTLS. Here you can create your own CA as you control all clients who are authorized to connect and can install the CA certificate. A simpler setup though is to have yor MTA listen on both port 25 and 587 and announce all services required for local delivery plus STARTTLS. Then require TLS for authentication. I understood you use dovecut as MDA? which is your MTA? With postfix the above is pretty simple to set up. BR, Erik -- M: +34 666 334 818 T: +34 915 211 157 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On Sun, 24 Mar 2013 18:59:09 +0200 l...@lena.kiev.ua articulated: Bad idea. Legitimate users connecting from dynamic IP-addresses is normal. I disagree. There is no legitimate reason a user cannot use a bonafide ISP to send mail. I block dynamic ISPs by default. I have found that 99% of it is just SPAM or some asshole attempting to relay thorough my system. If a user cannot afford to get a STATIC IP, then I cannot afford to waste my time with them. Just my 2¢. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
Jerry je...@seibercom.net wrote: How about refusing to relay mail from addresses in a good DNSBL? Bad idea. Legitimate users connecting from dynamic IP-addresses is normal. I disagree. There is no legitimate reason a user cannot use a bonafide ISP to send mail. The talk is about RELAYING mail sent with authentication when legitimate users travel and connect from another ISP. When you send mail from a mobile, should your relay (you use Gmail) block you because you connected from a dynamic IP-address? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Client Authentication
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Client Authentication
On Sat, Mar 23, 2013 at 9:22 PM, Doug Hardie bc...@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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
