2 Factor Authentication for Web+Center

2 Factor Authentication For Web+Center

We need your input to help us design a 2F authentication process that works for your Web+Center environments.  The information below shows our designs so far but we are still in the design and implementation phase of this final feature for V10.

Current Login Methodologies:
Web+Center currently has two types of users, “techs” and “customers”.

• Techs can login in now with a TechID, or username, or email address and password.  That password never expires or forced to be re-entered.
• Customers have two distinct ways to login into Web+Center.  They can use the default “Web+Center database” customer login by using Customer_ID, or email address or customer username and a password.  Or customers can authenticate to access Web+Center with an Microsoft Active Directory integrated login.  AD logins are authenticated entirely through AD with AD storing usernames and password and maintaining the integrity of the login information (username/passwords).

Once a customer or tech logs into Web+Center, a session cookie is created that is only saved while the user is logged into that browser session.

If a customer or tech wants to replace their password, a reset mechanism is available by requesting a password reset email associated with that account.  We would refer to this as single authentication.

If an account was compromised and a non validated user obtained the password to log into an account, they could continue to use the account as there is no forced  re-authentication or force password resets on any of the Web+Center accounts now.

2 Factor Authentication –
Many devices like iPhones or applications provided by Google or Microsoft force 2 factor authentication now.  When you enable a service or application,  your original account setup requires that you enter at least (2) ways to verify your valid identity.  For Web+Center, we plan to use email and TXT SMS or phone call voice messaging as the two methods to authenticate the users.

Smarter and more secure logins
With this new version of Web+Center, we are going to examine the login header information more carefully and look at past login failures  and if necessary we will force the user to provide a second factor of authentication to access Web+Center.

We will also keep track of the number of consecutive login failures and block future login attempts for 30 minutes after 5 failed attempts.

We understand that many of our systems out there already just have a simple single email authentication option available so we plan to make the 2 factor authentication option very configurable to match your security requirements currently and going forward.  We don’t want users to be frustrated by continue re-authentication requests but we also want to prevent any un-authorized use of the application.

Here is our planned design for 2 factor authentication – system configuration and user login requirements

System Level Configurations
As the Web+Center configurator, you will be able to control the various 2 factor authentication options available for your users.

Tech 2F authentication options

• No 2F authentication
• 2F enabled by technician
• 2F forced to all techs
• Force 2F re-authentication after X number of days

Customer 2F authentication options

• No 2F authentication
• 2F self enabled by customer
• 2F forced to all customers with Web+Center DB login
• Force 2F re-authentication after X number of days
• Active Directory Logins + 2F self enabled by customer
• Active Directory Logins + 2F forced to all customers

Login 2F Authentication Required Triggers
These are the rules by which customers or techs will be required to authenticate themselves before they can continue to login in.

Valid Device Login IP and Date/Time – Each time a tech or customer successfully logs into Web+Center, we will store this device IP login address for the next login into the database in a value called LastSuccessfulLoginIP.  We will also record the Date/Time of that login.

If the user is logging on with a different device login IP, we will force the second 2F authentication before allowing a log in if 2F is enabled.

If 2F is enabled and number of days between the last 2FAuthentication has passed, it will force another re-authentication.

To provide both SMS and voice call verification codes, we are current programming our 2F authentication options around the Authy API from Twilio.  We already support the Twilio SMS  API, so adding this feature if you have an twilio account is fairly easy to implement.

So even if users do not have a smart phone or TXT SMS access, they can still get authentication codes delivered by a voice call.

The Twilio API sends the TXT message/voice call from generic 2F authentication source that is only valid for 10 minutes and that code has to be confirmed within that time period.