33
Two Factor Authentication for SmarterMail - when?
Idea shared by Webio - 11/7/2014 at 3:36 AM
Completed
Hello,
 
when we can expect to have two factor authentication for SmarterMail?
 
Regards

68 Replies

Reply to Thread
1
Two-factor authentication would be a very nice touch. The capability to send a text message, with a 6 digit auth code, or interface with an external service would really help tighten security.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
I was recently using this:

http://www.codeproject.com/Articles/403355/Implementing-Two-Factor-Authentication-in-ASP-NET

to add two factor auth to my app. It uses existing auth app like Google Authenticator, OATH Token for iOS or Authenticator for Windows Phone to provide time token for logging in. Code on codeproject is complete and opensource and adding it to existing app is very easy. Of course mail server is way more complex (for example how to solve SMTP auth) but I'm just pointing suggestion how this could be programmed.
1
Most of my customers are well versed with the PayPal txt message model and would prefer that to an external token or device.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
By saying "txt" you mean SMS? IMHO this is additional cost which some people are not willing to take. Maybe best solution would be allowing to have multiple types of two factor authentications like it is with WHMCS for example:

https://www.whmcs.com/two-factor/
0
Very good idea
0
Hope SmarterTools will consider this way of authentication.
1
SMS is now free, for the most part, with plans in the US and is the bulk of two-factor authentication for hospital networks, PayPal and many other online financial services.  It is also used extensively by FaceBook and LinkedIN
 
Everyone has their cell phones with them all the time and would be a very convenient two-factor method to integrate.
 
Tokens get lost and cost extra money.  They also get left on desks in workstations, put in drawers, and left in pants and shirt pockets.
 
Your own example at: https://www.whmcs.com/, shows the use of SMS / text messaging and a cell phone and shows how densely it is implemented.
 
See the graphic of users on the pagehttps://www.whmcs.com/features/
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
3
I totally agree this should be optionally implemented using Google Authenticator which I have recently been using for WHMCS. It works great and is easy to setup- cheap.
 
For that matter, reporting that last X IPs to access your webmail or POP/IMAP your account would be a nice feature too- if we're talking about security.
0
WHMCS allows 3 different ways of two factor authentication. One is hardware key - paid, second one is using external apps which I've mentioned - free and the last one is using SMS/push messages (from WHMCS website - "Pricing starts at just $3 per user, per month so it" is paid). Basically only one of them is free and this is the one which I hope it will be implemented.
4
There's no reason to introduce a paid add-on for two-factor authentication.
 
This code can easily be added to the login process, generate a single use SMS response code, which is sent to the user's phone mobile device, which, upon a proper response by the user, allows the users web based login to proceed.
 
The addition of the new password settings, along with strong passwords, and the use of password brute force, along with SMTP harvesting, provide great tools to protect the logins from mobile devices and clients like Outlook.
 
The are three other ELECTIVE enhancements I would like to see, in addition to SMS, or 3rd party, two-factor authentication:
 
  • the ability to exclude all words in the dictionary [a US CERT recommendation for password compliance];
  • the complete exclusion of the username in any password.
    • Right now, if the username is john@domain.tld, and the user inserts john in the password, and require password does not match username is checked, the password will not be accepted.  As soon as another character, letter, or number, is added to the username, the password becomes a valid password, and;
  • the ability to exclude the use of the same character more than X times in a row[.
The security of e-mail is of the highest importance.  E-mail is usually the primary key for all of a user's financial records, online tax filing, eBay, PayPal, FaceBook, LinkedIN, Microsoft, and almost every aspect of a user's login world.
 
If a user's e-mail account can be compromised, then the hacker who has gained access to that account can quickly change their password and attempt to hack their financial and social media accounts.
 
SUMMARY: add the following capabilities to the improved password management found in SmarterMail 13.X:
 
  • two-factor authentication, using SMS, via built-in code and SMS code transmittal, with the option of using other options and/or 3rd party add-ons;
  • completely exclude the use of the username or domain portion of a user's e-mail address from being used in the password;
  • the ability to exclude all words in the dictionary - it's far too easy to run dictionary attacks on passwords and takes only a few hours to run through an entire dictionary where a multi-honed attack is mounted and the mail server is sitting on a fast circuit;
  • allow the ability to restrict the use of the same character X times in a row, IE: if the trigger is 3 in a row, then disallow the use of any character 3 times in a row in any password,
 
 
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
1
Amen-- Bruce, all good ideas. This could be easily done with a little RegEx aside from the dictionary thing. I think Google Authentication would be better than SMS but it would be nice if customer's could choose either method. 
0
I agree with you, very good ideas.

1
While the tendency in these threads is to use Google Authentication, every site I have gone, which now allows two-factor authentication, uses SMS.  
 
Chase now enforces a 7 character SMS password before you can login from a new device; using a browser they don't recognize; or when you've cleared your browser's cache.  Because all of my browsers are set to clear both their history and cache every time I close them, I have to wait a second to receive the code and enter it to login to my Chase account.  It's a five-second code.  If you wait more than 5 seconds, or enter it wrong and take too long to re-enter it, you must request a new code.  They also give the option to receive the code via e-mail or via automated voice prompt, but only to verified telephone lines, already associated with your account.  If you don't have access to that data, you can still access your account by entering a full credit card number, expiration date, and one of your security questions.
 
Here's a great article, published in Huff Post Business, that boils the necessity for two-factor authentication down to laymen's terms: 

"Certain websites included in phishing emails successfully lure users up to 45 percent of the time, according to the study, which came out on Thursday. Once on the bogus pages -- which tend to imitate legitimate sites, like Google itself, in an effort to obtain people's private details -- 14 percent of people unwittingly submit their information to hackers. Researchers said the percentage of people who get tricked was "much higher" than they expected."

The report goes on to say: "
Once a hacker is able to access someone's account, they spend an average of three minutes figuring out how much it's worth, and will apparently move on if the account doesn't seem valuable enough. According to the study, hackers use Gmail's own search function to figure out if an account is worth their time, looking for terms like "wire transfer" and "bank."
 
What happens next probably won't surprise you: The hacker tries try to get money from an account's contact list. They send emails to the person's friends, family and colleagues with fake stories like "we were mugged last night in an alley" in the hopes of getting them to send cash.
 
Google's advice for staying safe? Enable two-step verification on your email account, and report any suspicious emails instead of responding to them. And if you suspect your account has been compromised -- maybe because you've belatedly realized that something seemed off about the website you visited, or because a friend has asked you about the weird email they just got from your address -- you should work as quickly as possible to regain control. Twenty percent of hackers access compromised accounts within 30 minutes of getting their credentials, the study says."
 
The complete Huff Post Business article is available at: http://www.huffingtonpost.com/2014/11/07/phishing-scams_n_6116988.html
 
The original Google report is available from Google's Online Security Blog at: 

http://googleonlinesecurity.blogspot.com/2014/11/behind-enemy-lines-in-our-war-against.html
 
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
What do you mean "SMS is now free"? Who offers a commercial API that can be used to send free text messages? And to international networks?
0
From Sprint:

"Address the mail message to the recipient's phone number in the Sprint PCS messaging format. The email address should be the 10-digit number at the domain "messaging.sprintpcs.com." For example, if the number is 123-456-7890, the email address would be 1234567890@messaging.sprintpcs.com. Send the message."

Count the characters in the final message to be sure the total is under 160 characters. The Sprint network will display only the first 160 characters of a text message, as that's all the system supports.

SmarterMail already handles this quite well. Just send a test of a code to your phone, from your e-mail, without a signature or subject, and you will receive it very quickly.

This can easily accommodate the SMS two-factor authentication requirements of any mobile provider in the US.

Here's the format for the US carriers:

- AT&T – cellnumber@txt.att.net
- Verizon – cellnumber@vtext.com
- T-Mobile – cellnumber@tmomail.net
- Sprint PCS - cellnumber@messaging.sprintpcs.com
- Virgin Mobile – cellnumber@vmobl.com
- US Cellular – cellnumber@email.uscc.net
- Nextel - cellnumber@messaging.nextel.com
- Boost - cellnumber@myboostmobile.com
- Alltel – cellnumber@message.alltel.com
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
This is a very incomplete solution, so not useful in real world applications. It is not universal, so could only work in closed environments where you do not have any international customers or US customers that use local providers when traveling internationally. Also, trying to use this requires you to capture both the mobile number and the provider. Not very customer friendly.
0
I am certain similar capabilities exist with carriers in other countries.

The whole point is to implement the easiest possible solution for the end users at the least expense to the SmarterMail server operator.

My preference is the solution which has repeatedly been implimented, and proven, by Google, PayPal, Chase (and many other banks), Facebook, LinkedIn, and myriad other providers: SMS.

It's simple, elegant, and does not require anything but a cell phone. It can also be adapted to a backup e-mail.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
We already use SMS for two-factor authentication, but that isn't the point. You mentioned a free option, but your option requires the application to know which provider each and every user has. Have you ever been asked for that information for two factor authentication? That certainly wouldn't qualify as "the easiest possible solution". A solution where you don't need to know which provider someone is using is what is necessary, not the provider email to SMS option.
2
Somewhat security related, it would also be nice to optionally enforce CAPTCHA on the web interface - I know it's of little defense against brute forcing via the other protocols, but it does generally defeat script kiddies brute forcing a forms based web page...Just a thought...

TJ
0
Nice thought
0
Honestly, I would like to see both as an option, but I've had trouble previously with SMS to email gateways, IE number@vtext.com, et al. So unless they option to add an SMS gateway, ie celluar USB, I would stick to Google OAuth as well. No complaints though on dual factor, though now I definitely need a fully charged cell phone to pretty much get anywhere on the web using 1Password, OAuth, and others... Welcome to security ;)
1
Regarding email security: What google gives with one hand, it takes away with the other:  If you use gmail from a browser, there's currently a checkbox on the login screen that says "stay signed in" and is checked BY DEFAULT.  You must uncheck this before sign-in if you don't want the gmail login to be persistent.
 
This means that in most cases (because browser cookies are typically turned on), if you close the browser tab or browser without logging out of gmail, you will still be in gmail when gmail is launched again from the browser, even if the browser and computer are shut down and re-started. It's even possible that your activities are still tracked by google while the browser is open, even if gmail (or another google page) is not launched.  I have, on more than one occasion, allowed someone to use my computer, only to find, when opening gmail, that I have full (and un-desired!) access to their account.
 
Since many people use gmail as their default email client, this represents a potentially serious security breach. Without two-factor authentication, access to gmail gives a potential hacker the ability to change passwords for other accounts (but see the last para for a potential glitch, even with two-factor).
 
And the button to logout is buried inside at least one additional click. Unfortunately, this behavior is common for many other highly popular web portals, such as ebay, amazon, yahoo and facebook. They know that making it more difficult to log off allows them greater opportunity to track your online movement (Glad to say that SM's logout link is precisely where it belongs, at top-right of screen).
 
I am "pointing the finger" at google in this case because they claim to be at the forefront regarding Internet security. But that automatic "stay signed in" is pretty worrisome IMO.
 
Of course, if someone with bad intent gets a hold of your smartphone, and there's no PIN lock, and your email client(s) is/are wide open, AND you use SMS authentication for something, you might just be screwed.
 
There oughtta be a law.... 
 
2
Employee Replied
Employee Post
I want to thank everyone for the discussion on two-factor authentication.  At this time, I am adding this to our features request list for further consideration by the dev. team.  We will discuss the various methods of two-factor authentication mentioned above.
0
Thanks, Roger.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
hi @SmarterUser, can you explain-share how you integrate SmarterMail with an SMS gateway or service to allow 2-factor authentication please?
0
Good and valid concerns, Paul. As someone who is not as well versed in the actual programming aspect of these tools, I am curious, and would welcome a reference with which I could learn more, about the possibility of making this work as "ASP.NET, or another type of, server side" calls. As I understand the capabilities of server side includes and calls, it's a lot easier to prevent the storage of passwords and/or cookies after a session. This thread has been a wealth of ideas and information, so far, and I see no reason to stop sharing ideas or potential solutions.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
1
Two-factor would be great, but unless we can keep SM from logging people out all the time, people are not going to like having to type in the authentication code all the time- once, twice a day okay but many times won't be accepted.
0
I think two-factor, when available in SM, should be optional, activated on request of the mail server administrator, and should allow people to opt-out of two-factor authentication on certain (e.g. their usual home or office) machines. In this case, some education is needed so they are aware of the seriousness of their opting out on shared and/or (especially!) public machines. And on smartphones, well, a strong screen-lock pattern or code is a good idea; not easy to enforce, but welcome to the Wild West.
0
@Paul Blank:
 
While I understand your desire to have the ability for users, especially in offices, to NOT have to do double authentication, the HITECH portion of HIPAA, now mandates the EVERY logout, whether elective, or enforced for time-out reasons, must use the full authentication protocol for every login.
 
If the user has elected to lock their workstation, then a standard login can be used - with the second factor, to unlock the device.
 
However, if an EHR, or another program like SmarterMail, running under a locked screen, on a user's computer, or web enabled device, has auto-logged the user out, because of a time-out.  This is a separate action from the computer, workstation, or terminal device, and is not covered under the security policy established for the overall network login.
 
Additionally, for all HITECH covered properties under HIPAA, we must now keep LOGS of all actions performed:
 
  • the logs must be kept in a, SEARCHABLE, READ ONLY format, accessible by only those named in HIPAA/HITECH/NETWORK document management policy and then ONLY by those persons who are either authorized employees, or outsourced employees who have a current, annually renewable, letter of agency on file - individually signed.  (As of March, 2014, every employee for every agency, colocation hosting group, support group, etc, must have an individually signed letter, whether they have access to the actual customer data or not.  If they are an employee, then they must sign a letter of agency with their employer, and a copy of that letter must be on-file, with the customer who's network they may have the potential to work on, whether remotely or on-sight.
     
  • who logged in, at what device, using what username, on what date, and at what time, including minute and second.  We must also know what programs or documents, covered under HIPAA they looked at (even if they just opened and closed them); if they modified them; if they printed them; if they converted them to a PDF; and if they e-mailed or shared them - via any other manner, and to WHOM they were shared.  If they were printed, we must log what printer was used.  Those logs must also include the DATE and TIME.
     
  • when accessing data within any EHR (electronic healthcare record) system, the logged in individual's action, must also record, within the EHR system, the following data:
     
    • the username, login, and IP address(es), along with the date and time, of the workstation from which they are logged in; 
    • the FQDN, from ACTIVE DIRECTORY, of the network to which they are attached; the username, date and time of the login to the EHR software; a complete record of every screen accessed by the user who is logged into the EHR system, while within the EHR system;
    • the patient record number/name of every patient looked up within the EHR system, while logged in;
    • what patient record screens are looked at; what data is accessed, modified, changed, or otherwise accessed, along with date and timestamps;
    • a record of any data added, changed, modified, exported (including file name and path), with date and time;
    • a log of any data e-mailed to a co-worker, another medical facility, doctor, hospital, patient, etc, including date and timestamp, along with the SMTP server used, a record of the software type, whether built-into the EHR system or via an external SMTP service or program;
    • and a record of the date and time of the logout from the EHR system.

       
  •  in the case of SmarterMail, we must require extremely strong passwords, setting a minimum length of 12 characters.  We require upper and lower case letters, numbers, and special characters.  We do not allow the inclusion of any portion of the username, or the domain name, and are taking advantage of the new "disallowed words" table to augment some of that information so the user can automatically change their passwords.   NOTE:  We have filed a letter of opinion to the forced password change table, presenting the fact that the use of a strong password, or passphrase, which is extremely secure, and easily remembered by the user, is much more secure than shorter passwords which must be changed every 30 to 45 days, and causing distress for both end-users and support desk personnel.
     
  • We must archive all of the IIS logs, associated with any web, REMOTE DESKTOP EHR access, remote server maintenance access, SmarterMail web access.
     
  • We must archive all POP, IMAP, SMTP CALDAV/WEBDAV, and ActiveSync logs.
     
  • All of the above referenced logs, whether network, EHR software, or SmarterMail, must be ARCHIVED for a period of 60 months.
     
  • We have disabled all PLAIN TEXT logins, enabling TLS only security - enforcing TLS, point-to-point security through SmarterMail connections.
     
  • If we receive a LEGAL or INSURANCE inquiry, we must STOP THE ARCHIVE CLOCK on all of the LOGS for the patient's medical records which were accessed by any of the following:
     
    • employees,
    • medical providers,
    • imaging department;
    • billing department;
    • IT support department,
    • any outside consulting group,
    • all management and accounting staff,
    • anyone within the general office staff, whether they have access to the EHR system or not;
    • anyone else who may have accessed the network, EHR, SmarterMail system, or any other portion of the data stored on the network;

       
  • The STOPED LOG CLOCK, initially based on the initial END DATE of the archive of all of the data: network, e-mail, EHR, document, or any other aspect of that data, must remain stopped and locked, until there is an outstanding resolution on the inquiry received. 
     
  • In the case of a legal inquiry, this means that the STOPPED CLOCK remains frozen until all inquiries, court cases, discoveries, verdicts, settlements, agreements, or appeals, and associated appeals actions, have been completely settled, at which time the RETENTION CLOCK starts all over at ZERO, and the LOG records must be retained for another 60 months for all documents associated with the inquiry. 
 
I only bring up this incredible detail because Paul Blank, myself, and several others, both within this post, and via other posts, have all related that e-mail, network, and other security, is not a simple issue.
 
The HITECH portion of HIPAA has, for the last 7 years (or more), mandated that IN SERVICE EDUCATION and TRAINING  be provided for NETWORK, EHR, E-MAIL, and general Web and Internet security, be conducted at least once a year. 
 
The HITECH portion of HIPAA has also mandated that an ACCEPTABLE USE POLICY, for Internet, Network E-Mail, and EHR, be developed, and regularly kept up to date.  Prior to a couple of years ago, this was not required to be part of the IN SERVICE / EDUCATION program with the healthcare organization.
 
Prior to December, 2014, conducting of regular IN SERVICES / EDUCATIONS was not always a normal procedure in most environments.
 
OCR, the Federal Agency which regularly conducts Meaningful Use audits, has now notified all healthcare agencies, that they would be allowed to skate on security procedures or regular educational in services for all medical personal, and would begin to take serious actions against any healthcare group, hospital or agency who was not in complete compliance. 
 
They made a couple of examples, and have begun, in earnest, to become more aggressive, in their meaningful use and HITECH audits during the last few weeks.
 
If we are going to provide e-mail services, via SmarterMail, to any of those agencies, or groups, from the smallest Doctor's office or neighborhood not-for-profit healthcare group, to the largest hospital or research university, then we need to work with SmarterTools to ensure the preparedness of the SmarterTools family of products via shared communications and ideas.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
I have integrated Twilio's SMS/MMS API into some of my client's websites. But at a cost of about 1 cent per SMS and 2 cents for MMS, plus $1 per month for each outgoing long code I wouldn't call it free. The other problem is many of the carriers throttle messages when they come too fast. so you would have to get multiple long codes depending on the kind of volume you are sending, and round robin them. If you know of another way to do it, I would love to hear it!
WhiteSites.com Blog.whitesites.com
0
Also you can forget about the email gateway method. I have been there and done it. Its not fast enough. Some times messages take minutes or hours to arrive, plus carriers throttle the messages. I want to say that sprint throttles it down to 50 messages per hour. The other issue is when a user sends a reply to the text it doesn't always come back from the 10 digit number. Sometimes it comes from a more friendly email address, which prevents you from doing a lookup on who sent the message.
WhiteSites.com Blog.whitesites.com
1
+1, 2FA is the way of the future and email is definitely important enough to make this a requirement for a lot of companies. I wouldn't be surprised to see this become a PCI requirement in the coming years. Unfortunately there is no support in email clients for IMAP/POP/SMTP so these should use  "Application-Specific Passwords" like Google does it..
 
As far as Google Auth vs SMS vs email-to-SMS gateways I would suggest Google Auth *and* SMS via Twilio be supported. This way a free/simple solution is included out of the box and for users that want SMS they can sign up for Twilio and enter an API key.
0
I spoke about a number of issues related to this at in a post titled "forums.smartertools.com/threads/enhanced-security-is-needed-more-then-ever.41674/" which I can't see to find.

I've written ASP .NET code to integrate with Google Authenticator and equivalent for iPhone and other devices. Under the covers Google Authenticator implements its time base security tokens based upon RFC 6238. It took a while to get the RFC 6238 hashing function to working, but, its doable as the RFC provides the algorithm and testing values and responses.

Many of the Mobile Apps that work just like Google's Authenticator also use a QRCode to import the Hash Seed which is great because type a long seed value is difficult to enter by hand. Its easy to use the camera on a mobile device to capture the QRCode from screen or paper. With many RFC 6238 mobile apps around it make this a good choice! I print out my QRCodes on paper and key them offline in a secure place so that if required I can reload the Hash Seed onto a new device or multiple devices as may be required until it can be replaced.

As mentioned as POP/SMTP/IMAP connections do not support two factor; then we will need a machine passwords. It should be easy enough for a password to be checked against the multiple additional passwords along with the "main password".

For the machine passwords I would suggest using One-Time-Password (OTP) hashing function and for example I might suggest RFC 2289. I could not find an RFC for Random Password Generator although a good discussion can be found here at this url: en.wikipedia.org/wiki/Random_password_generator.

The Smartermail 2FA solution should also support OTPs that are sent via eMail. SonicWALL does it this way at the present and it works well of course you have a slight delay. As discussed you can send SMS messages for free using the common eMail-to-SMS Gateways, however, each gateway has its own message conversion quirks that someone should investigate. Not all SMS Gateways are MIME friendly (AT&T is one of them for example).

Then this begs the question of how does a customer perform password recovery if they can't get 2FA one possibility is to generate a OTP password list or a single OTP (keep them in safe place) for emergency or an alternate password recovery eMail. Amazon, Google and Hotmail have good and well known patterns that can be mimicked by SmarterMail.

This will truly be very welcomed especially for Admin accounts!
1
Add one more vote for the Two Factor Authentication.
1
As with other similar threads, I support this idea 100%...with one caveat:
 
Two-Factor Authentication must be a per-User opt-in (check box to enable in the General Settings for each user).
 
As odd as it may sound, not everyone has a smartphone and not everyone wants one...and even those that have one may not necessarily want to use 2FA as much as we Admins may want them to. It has to be an available security option, not a mandatory one. 
1
Scarab: two-factor authentication also needs to be able to be mandatory for an entire domain, depending on cotractual requirements and applicable security regulations. I have several healthcare and legal organizations who would l9ve to implimented this on a domain - wide basis.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
+1 for 2FA!
+1 for Google Auth 2FA Support with on screen QR Code Scanning by APP!
+1 for per machine passwords like Google!
+1 for eMailed one-time-passwords instead of Google Auth!
+1 for Twilio for Voice and SMS notifications!
 
Twilio is low cost but NOT free! SmarterMail should be able to get lower prices as they could aggregate the billing to save us end users money and for SmarterMail to make a reasonable profit! In addition, we would need counters to track Twillio notifications by type by user so that anyone can choose how to charge the end customer for this add-on service!
 
On the issue of 2FA settings for per user or per domain; SmarterMail already has this one solved in the UI! Like many options the SmarterMail Admin decides on the global settings to allow 2FA or Not by adding it to the feature list of a domain! This feature can be globally on or off!
 
Then the Domain Admin, just like the feature folder-auto-clean, the Domain Admin can opt out if allowed by the SmarterMail Admin and then decide which users get 2FA or not! You would have some of the opt in/out settings in the Domain Edit panel with a tab called 2FA?
 
Reuse the SmarterMail paradigm we already have in place!
 
In this way we provide for both Bruce's and Colin's requirements -- SmarterMail Domains are NOT a one size fits all!
 
 
1
Amazon recently added support for Google Style 2FA using Google Authentication or you favorite TOT/HOTP Auth App like Yubico, or Authy. Any ideas when this comes to SmarterTools! Don't forget we need machine passwords to be assigned to devices with long passwords that have 80 bit strength or about 20 characters (see www.wikipedia.org/wiki/Password_strength for details).
1
Add one more vote for the Two Factor Authentication.
1
Integration with https://duo.com/
1
+1 for 2-factor authentication/verification - would love to use our yubico's with smartermail or google authenticator application
Smarter Mail v13.3
0
Yubico U2F is great but only Chrome supports it natively and FF is struggling to incorporate it (there may be an addon for it - not sure TB)

Would love to see more of it
1
+1 for 2-factor authentication/verification - would like to use Google Authenticator with SmarterMail!
0
hi everyone 
it's simple to make an option for tow factor authentication and give it to the end user ,if they want to use that just enable it in setting , and today it's simple to active this option on any software (any platforms) just search "Google Authenticator" no need SMS or more thing . just mobile app and then finish 
 
1
Employee Replied
Employee Post
Hi everyone,
 
Thank you all for your feedback on this thread! We appreciate you taking the time to provide your input and thoughts on this functionality. We've had many discussions -- both internally and here in the Community -- about security improvements that can be made within the product, and I'm happy to report that 2-Factor Authentication is planned for a future version of SmarterMail! 
 
Though I don't yet have details regarding when this will be implemented or the type of authentication we'll use, I wanted to make it known that this WILL be coming to SmarterMail, along with many other security improvements and fixes. 
 
Thank you again for your participation, and stay tuned! 
0
Any further development or dates for this feature to be added to v16? It's been 6 months since this has any comments.
0
Employee Replied
Employee Post
Hi Case! This is still a feature we are looking to implement; however, it's not something that will be available in 16.x. That said, we have not only started working on 17.x but will be finalizing the feature set in just a few weeks.
3
Employee Replied
Employee Post
Hello All,
 
We are looking into implementing 2FA for SmarterMail17 but had some concerns we wanted to gather opinions on from the community. First, how would both System and Domain Admins actually go about implementing the 2FA within their system once SmarterMail supports it? Second, how are you going to handle moving thousands of users on hundreds of domains onto a 2FA system without becoming a support nightmare? We want to add 2FA in a way that will make it as easy as possible for both admins and users to work with, therefore, we want to be careful in deciding how we create the settings for it. We are considering having a general System Admin setting to enable 2FA for domains, then let domain admins either enable or force 2FA on their domain. We could also include settings for this on domains on the System Admin side to allow the settings to be propagated across domains.
 
Forcing 2FA across domains is going to be difficult in how we want to handle both people using webmail and those using other protocols. If a domain forces 2FA on the domain do we just want to immediately drop everyone and prevent them from logging in until the 2FA is setup? This could create problems for users that never use webmail: if they are not properly informed of the change, they simply can no longer access their email and their known password no longer works. We can also add a grace period as a setting for this to help mitigate the issue but we want to avoid creating more work for the support line that will have to deal with this, if possible.
 
Does anyone have any further ideas on making this process easier and making the process of setting up device passwords as easy as possible for the user? There are some other minor issues with protocols and device passwords also. For example, EWS does not actually give any device information so a device password for EWS will basically be usable for any EWS device that tried to connect (you can only have one EWS device connected at a time at the moment).
 
Regards,
0
Matt Petty Replied
Employee Post
Woo!
https://media.giphy.com/media/rl0FOxdz7CcxO/giphy.gif
Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com
0
Are you celebrating that it took 4 Years?
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
Matt Petty Replied
Employee Post
Sometimes things get pushed back. It's how software development works with a small team. No I'm not celebrating it taking a while. I was just trying to show my excitement that we have reached a point in development where we can start working on new and exciting features. I really don't know why you have to be negative about everything. I'm sorry you got burned in other topics, but it is kind of rude to waltz into the 2 factor thread and spread your negativity.
Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com
9
Matthew,
 
I don't know about others but for us having 2FA really, really, really needs to be a on a per-user basis. I'm fine with the option for System Admins & Domain Admins to set it for "Enabled" or "Force 2FA" as I understand the need for strictly enforced Group Policies in some organizational units but for ISPs and Hosting Providers we need individual end-users to be able to have the option to "Opt-In" (or "Override" Domain 2FA Settings) otherwise it will be far too burdensome to handle from a Tech Support/Customer Service perspective as not everyone on a domain uses the same login method...some will use webmail, some will use POP3, some will use IMAP, and some will use EWS, and some EAS, and not everyone on a particular domain will even be interested in adopting 2FA at the same time. Again, for those organizational units that do have strictly enforced Group Policies being able to force 2FA (and enabling an option to not allow users to override the 2FA setting) that is fine, but for those that don't it is important to allow end-users the ability to opt-in to 2FA on their own time when they decide to do such at their own convenience.
 
Take for example how Google Apps (now GSuite) handles 2FA. An Admin can enable the 2FA for their domain or even force 2FA for their domain but if this setting is only enabled and not forced then individual users can enable 2FA at their own convenience when they chose to opt-in, resulting in some users who may have it enabled while other users on the same domain may not.
 
In addition, System & Domain Admins will need a way to disable 2FA for individual users when they get locked out (because it will inevitably happen and it will happen often...probably every single time the user gets a new device, so every year or two) which makes it imperative that 2FA can be toggled on or off for individual users.
 
Lastly, making it as simple as possible for end-users with a perpetual case of PEBKAC would be ideal as most System & Domain Admins should at least be able to RTFM whereas end-users generally never will. (Again, GSuite is a good example of fairly brain-dead 2FA implementation for end-users.)
1
Derek Curtis Replied
Employee Post
Two factor authentication was released on December 3rd, 2018 with the release of Build 100.0.6911
Derek Curtis COO SmarterTools Inc. www.smartertools.com
1
Hello Derek,
   I am wondering if we are using Active Directory integrated. then 2 factor authentication is workable?
Is there any document I can refer? 
  Thank you
rds
Juan Lai
0
Hello,
We too are trying to see if we can enable 2FA for our users, but cannot seem to find it although it is enabled in the Domain Settings. We are using Active Directory - is 2FA possible for AD accounts?
Thank you!
0
Employee Replied
Employee Post
@Ionel, 2FA cannot be used when the user is configured to use AD authentication.
0
Thanks Robert, that is unfortunate to hear.
Is this something that can change in the near future? We would really need to have 2FA for email as we are using this for many other services and not being able to enable it for email (our most important means of communication) makes us not compliant with internal and client minimum security requirements.

Looking forward to some good news here, even if it will take a bit.
0
Kyle Kerst Replied
Employee Post
I believe the 2FA functionality would need to be implemented on the AD side correct? Since the authentication itself is happening via Active Directory, I think they'd need to be the ones to implement the 2FA requirement as we're letting AD handle the authentication approval. 
Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com
0
Well, no, please think about MS365 or even Outlook.com for example: they also use AD for user account management and have multi-factor authentication implemented. You can still configure email clients with their service and the clients (e.g. Outlook) do not use 2FA.

We, as probably many others, have many systems integrated with AD for authentication and some simply cannot use 2FA, so if it were implemented at the AD level that would be a major issue. But the majority of these systems are internal and not exposed to the Internet. However, WebMail is exposed to the public and we need all publicly accesible services to use 2FA.

I understand that with AD SM passes the authentication responsibility to Active Directory, but SM does not that authentication has taken place and is successful or not. After this, it goes ahead and lets you access the mailbox - surely an extra step could be inserted between the AD auth and the allowing of access. For example, at the first login an extra step to configure the timezone and theme is inserted. In short, let`s say now the authentication works like this:

  1. User navigates to mail.smtools.com and the login prompt appears
  2. User enters user/pass in the form
  3. The authentication is passed on to AD
  4. Somehow the information that the authentication is successful or not is returned back to SmarterMail 
  5. If the auth was successful, the user can proceed
  6. If you are at the first login, an intermediary page appears prompting you to choose timezone and theme
  7. The user`s mailbox opens and the user can see their emails
Maybe another step could be inserted, like this:

  1. User navigates to mail.smtools.com and the login prompt appears
  2. User enters user/pass in the form
  3. The authentication is passed on to AD
  4. Somehow the information that the authentication is successful or not is returned back to SmarterMail 
  5. If the AD authentication was successful, go to an intermediary page requesting another authentication method
  6. If this second auth was successful, proceed
  7. If you are at the first login, an intermediary page appears prompting you to choose timezone and theme
  8. The user`s mailbox opens and the user can see their emails
I doubt this is impossible, especially since we already have another service accessible by website, mobile and desktop apps and we log in with our AD credentials, then use 2FA with Google Authenticator for each.

Without this, SM is an uncompliant tool in an enterprise and I think it would greatly help if 2FA can be enabled for AD accounts as well. Looking forward to good news on this as soon as possible.With all the current hacks and security issues, everyone is scrambling for better security / more secure tools and SmarterMail now is suddenly not a tool we should be using from this standpoint, which is a shame.
1
I think it is an overstatement to suggest that SmarterMail is an "uncompliant tool in an enterprise" when the feature is there but you don't want to use it as designed.   If 2FA is mandatory for your organization, then you need to use mail-specific passwords.    Most enterprises have a multitude of password systems so users have a multitude of application-specific accounts, sometimes with inconsistent usernames.   

The lack of 2FA design in Active Directory is a huge problem, but the blame goes to Microsoft.  We have multiple 2FA mechanisms for our organization simply because every product has to build their own solution, as SmarterMail has done.

The issue is complicated because organizations, including yours, don't really want 2FA everywhere.  They just want 2FA for remote connections.    SmarterMail is at a disadvantage because it is a single-server architecture so it does not have a sufficient mechanism for distinguishing between internal and external connections, so 2FA is either always on or always off.  This is something that they might want to address in the future.
0
Well, of course I did not mean that it`s completely uncompliant from all aspects. I was referring strictly to the subject of this thread, 2FA as it has recently become a big subject. Our clients demand we have 2FA for all internet facing services and unfortunately this is one of the last service we have that does not. We will have to abide by this policy sooner rather than later. 
Honestly, I do not care if it were implemented on the AD itself or not, although I do not understand how that would work. I`m trying to imagine a scenario:
  1. User navigates to mail.smtools.com and the login prompt appears
  2. User enters user/pass in the form
  3. The authentication is passed on to AD
  4. AD requires 2FA - how and where would one enter the 2FA code since I`m logging in to SmarterMail webmail interface?
If AD 2FA would work just fine with SmarterMail and all other services, then sure, by all means. 

What do you mean I do not want to use the feature that already exists? Most enterprises use some form of centralized authentication management. I hope you do not seriously suggest organizations forgo centralized authentication systems such as AD and others and instead use separate credentials for all their systems.. Security is a compromise and no solution is ideal, but having a different user/password for 20 systems and managing them all (both from the user and administrator standpoints) is far worse than having one set of credentials and point to manage them, where you can enforce policies, etc. I`m no advocate of Microsoft or other solutions for that matter - we use what we find to best fit the purpose.

Now, back on track, I do not think it`s impossible to have 2FA in SmarterMail for AD accounts as well, since there are other web-based services that offer the same setup. It just needs to be looked into and a decision being made.
I understand that many people administering SmarterMail and which post here are service providers, but if enterprises also use it for them with AD authentication, I`m sure that eventually more will run in the same problem we did and this will come up again.
0

We use AD for a lot of things, but we also have a bunch of application logins that do not use AD.  For those, we try to keep consistent usernames and the users tend to keep consistent passwords.   Many organizations will use a password management product to remember all of a user's passwords and type them into the application.  The use of a password manager also permits use of computer-generated password strings that the user does not know or remember, because the password manager does so for him.  

I don't think there is an organization on the planet that is able to say, "We will not buy this product because it does not use AD for authentication,"   So if you want 2FA for SmarterMail, you switch from AD authentication to SmarterMail authentication, then either help the user set his password to match AD or help the user get the SmarterMail password integrated into the corporate password management solution.

2FA is a can of worms because the application developer has to decide:
  • Which delegation system(s) to support:  RADIUS, TACAS+, LDAP,  and/or ActiveDirectory.
  • Which second factor options are necessary to cover all user situations.   The more diverse the user base, the more technologies are needed for the second factor.  In particular, assuming use of a cell phone is not an option in many situations.   Some users do not have cell phones, some will not want to install work software on a personal phone, and some employers want employees to keep their phones out of sight so that they get their work done.
  • How to implement the two logins.   
    • If a single-stage login mechanism is used, this limits the technologies available for the second factor and therefore the user communities that can be served.   
    • If a two-stage login process is used, and the primary factor must complete before the second factor is solicited, then the account is vulnerable to, and defenseless against, password-guessing attacks that will denial of service.  
    • With some two-stage login sequences, it becomes difficult or impossible to ensure that both logins represent the same identity.  Failure to ensure same identity means that a successful first-stage login can be used to launch a password-guessing attack against other users accounts, probably with weak audit trails.   
    • Whether a network connection is available.   One of our 2FA technologies assume that the user will have a network connection from his cell phone to our server.   But it uses a non-html protocol over port 80.   We have users in locations where cell coverage is hindered by their building and the guest wifi blocks the non-html traffic on port 80.   So they have to run over to a window to get the 2FA code.   Authenticator one-time-passwords do not need a network connection, but the organization has little or no control over which devices have been configured with the token.
Email has the additional problem that fat clients do not support 2FA at all.  So the SmarterMail approach is to use a difficult-to-guess computer-generated password for those clients.  This is a defensible design given the constraints, but is still a 1FA login solution.

One of the benefits of application-specific logins can be risk reduction.   If a SmarterMail-only password is compromised, only SmarterMail is affected.  If an Active Directory password is compromised, then lots of things are vulnerable.  Of course, if the SmarterMail credentials are compromised, and the AD credentials are identical, then the risk is equivalent to having AD authentication.

Overall, it is a big can of worms, and there is no one-size fits all problem.   Trying to cover all of the bases will require a lot of custom code to integrate with multiple delegation technologies and multiple 2FA solution underneath those delegation servers.

As I said before, my biggest objection to SmaterMail 2FA is that I cannot distinguish between internal and external connections, and I don't wan to use 2FA for internal connections. 

0
Thanks for all the technical details, but all I can take away from there is that it`s complicated and all a compromise. We have already weighed the pros and cons of having separate logins vs centralized ones. We come from a background where nothing was centralized and honestly it was much worse.

However, SmarterMail already supports AD and has a form of 2FA implemented, just not for AD accounts. So I do not think we`re talking about a fundamental code rewrite. But anyway, I`m asking and would like an answer from SmarterTools if that is possible, thank you. Anything else is simply unproductive. We know it`s hard, that it`s Microsoft`s fault, etc.. it`s the same story everywhere for most tools until someone mans up and does the job, then it`s suddenly not impossible anymore. 
I have LITERALLY had this same conversation with people from many other software tools we use and the first reaction is always to bash Microsoft and say it`s their fault, that AD is a mess and insecure (I dispute neither), that it`s impossible, etc. Then 2 versions later, lo and behold, we announce that now we support AD authentication, then one more version later, 2FA with that. We are now using 2 such tools, not one - I`ve already been through this exact same discussion :)

Maybe SM can make it work, maybe not, but I would like to hear it from them so that we can make an informed decision. Maybe it`s not possible now, but may be in the near future, who knows. We`ve stuck with SM for them promising features before. 
1
Hey Ron, would love to hear how that would work - having the 2FA implemented at the AD level - can you please expand on that? If we take these steps:
  1. User navigates to mail.smtools.com and the login prompt appears
  2. User enters user/pass in the form
  3. The authentication is passed on to AD, so AD receives the credentials
  4. AD decides that the received credentials are OK and also requires 2FA - how and where would one enter the 2FA code since I`m logging in to SmarterMail webmail interface? Maybe I`m away on my phone, not in the company.
  5. Let`s say the user performed the 2FA for AD, now AD decides that both the user/pass combo and 2FA code was correct, so it returns the info to SmarterMail that the authentication succeeded - from SM`s point of view it is still a one-step authentication. SM asked AD to verify user and AD said yep, it`s him alright. No matter how many steps AD verified, it still sends one info back.
So I still think that the 2FA needs to occur on the application itself. The idea is to have different authentication providers/methods - if SM defers the whole authentication process to AD, it`s still a single point of failure.

An no, we do not want to enable 2FA for ALL internal services that use AD for authentication. But having 2FA on all internet-accessible apps is common sense and something anyone should have nowadays. 
0
Hello ST team,
   
   I am thinking the same thing as well: how can I receive and response the 2FA from AD if I am logging into SmarterMail Web?
Well, you know, too many hacking attempts nowadays..

rds
Juan Lai
2