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.

Ban User

Ban IP Address

Delete Confirmation

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:

Ban IP Address

Delete Confirmation

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.

Ban IP Address

Delete Confirmation

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.

Report Abuse

Offensive Content

Wrong Category

Spam

Ban User

Are you sure you want to ban this user?

Ban IP Address

Are you sure you want to ban this IP Address?

Delete Confirmation

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,

Ban IP Address

Delete Confirmation

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.

Ban IP Address

Delete Confirmation

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."

Ban IP Address

Delete Confirmation

"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.

Ban IP Address

Delete Confirmation

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.

Ban IP Address

Delete Confirmation

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.

Report Abuse

Offensive Content

Wrong Category

Spam

Ban User

Are you sure you want to ban this user?

Ban IP Address

Are you sure you want to ban this IP Address?

Delete Confirmation

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...

Ban IP Address

Delete Confirmation

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 ;)

Report Abuse

Offensive Content

Wrong Category

Spam

Ban User

Are you sure you want to ban this user?

Ban IP Address

Are you sure you want to ban this IP Address?

Delete Confirmation

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....

Report Abuse

Offensive Content

Wrong Category

Spam

Ban User

Are you sure you want to ban this user?

Ban IP Address

Are you sure you want to ban this IP Address?

Delete Confirmation

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.

Ban IP Address

Delete Confirmation

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.

Ban IP Address

Delete Confirmation

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.

Report Abuse

Offensive Content

Wrong Category

Spam

Ban User

Are you sure you want to ban this user?

Ban IP Address

Are you sure you want to ban this IP Address?

Delete Confirmation

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.

Report Abuse

Offensive Content

Wrong Category

Spam

Ban User

Are you sure you want to ban this user?

Ban IP Address

Are you sure you want to ban this IP Address?

Delete Confirmation

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.

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.

Ban IP Address

Delete Confirmation

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.comBlog.whitesites.com

Report Abuse

Offensive Content

Wrong Category

Spam

Ban User

Are you sure you want to ban this user?

Ban IP Address

Are you sure you want to ban this IP Address?

Delete Confirmation

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.comBlog.whitesites.com

Report Abuse

Offensive Content

Wrong Category

Spam

Ban User

Are you sure you want to ban this user?

Ban IP Address

Are you sure you want to ban this IP Address?

Delete Confirmation

+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.

Ban IP Address

Delete Confirmation

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.

Ban User

Ban IP Address

Delete Confirmation

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.

Report Abuse

Offensive Content

Wrong Category

Spam

Ban User

Are you sure you want to ban this user?

Ban IP Address

Are you sure you want to ban this IP Address?

Delete Confirmation

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.

Ban IP Address

Delete Confirmation

+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!

Report Abuse

Offensive Content

Wrong Category

Spam

Ban User

Are you sure you want to ban this user?

Ban IP Address

Are you sure you want to ban this IP Address?

Delete Confirmation

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).

Ban IP Address

Delete Confirmation

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

Report Abuse

Offensive Content

Wrong Category

Spam

Ban User

Are you sure you want to ban this user?

Ban IP Address

Are you sure you want to ban this IP Address?

Delete Confirmation

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.

Ban IP Address

Delete Confirmation

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.

Ban IP Address

Delete Confirmation

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).

Ban IP Address

Delete Confirmation

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.

Ban IP Address

Delete Confirmation

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.)