Mi-Token has been delivering authentication solutions to financial, enterprise and government institutions for almost ten years. Mi-Token was designed from the ground-up to provide a seamless experience for administrators and users, while reducing the cost and Complexity of Two Factor Authentication (2FA) security
Mi-Token provides multi-factor authentication in a variety of security scenarios including:
•VPN remote access (including Cisco AnyConnect, Juniper SSL VPN, Citrix NetScaler and
NetMotion, etc)
•Access to on premise applications (including Exchange, Remote Desktop, SharePoint and
custom web-based portals)
•Single Sign On (SSO) for cloud based applications (such as Office 365, Salesforce or any
other SAML-enabled solution)
•Any RADIUS complaint infrastructure (ranging from cloud based Amazon AWS Console
to on premise managed Ethernet router).
Why Mi-Token ?
High Availability - No Single Point of Failure
When Mi-Token installer runs, it creates a local instance of a distributed database which is not unlike Active Directory (AD) database used by Microsoft domain controllers. It’s a lightweight version of AD database called AD LDS. After the installer finishes, (which typical ly takes about a minute), the newly created instance of AD LDS database immediately starts replicating in a bidirectional manner with other database instances used by Mi-Token components installed on other servers. As a result neither the Mi-Token software nor the database underpinning it represents a single point of failure.
Speed and Reliability - No Remote Database Access
When one logs into a Windows domain their password is verified by a domain controller against an internal AD database. For the users of the same domain this database resides on the domain controller itself. If it was remote then AD would have only a fraction of its speed and reliability. When one logs into a system protected by 2FA, their one-time password (OTP) is verified against a database which then needs to be updated to prevent a replay attack when the same OTP is used twice. In the Mi-Token case this database is always local, no authentication decisions are ever made using a remote database
Security - No Custom Authentication Server
Mi-Token makes authentication decisions without a dedicated Authentication Server (AS) commonly responsible for this functionality. The AS usually sits behind a firewall and validates or rejects authentication requests based on user credentials including one time password (OTP). Firewalls are commonplace and bear the brunt of external attacks, yet the number of system breaches has not subsided despite the implementation of firewalls in most environments. This makes robust security of the components behind the firewall paramount Mi-Token avoids deploying a dedicated AS ensuring that when you decide to implement 2FA, security is indeed increased rather than is influenced by having an AS which might not have been sufficiently hardened or is being patched on a schedule different from the operat ing system security updates.
Functionality
VPN Access
Mi-Token offers a Plugin for Microsoft Network Policy Server (NPS) which evaluates an OTP supplied during the login process and helps NPS to make authentication decisions. As a result, Mi-Token doesn't employ a custom AS which a firewall or VPN appliance has to be connected to. The AS which makes decisions to accept or reject users needs to be hardened against hackers and this requires an extraordinary amount of resources with rather prohibi tive cost. In case of Mi-Token the NPS already hardened by Microsoft plays the AS role. The NPS consults the Mi-Token Plugin while making the authentication decisions. If NPS decides it has come under attack then it won't consult the Mi-Token Plugin which derives security benefit from running inside NPS. Another consequence of this approach is the simplicity of Mi-Token integration into an existing VPN solution.
ADFS Plugin
The integration between ADFS and Mi-Token is achieved by using the ADFS Plugin. It requires ADFS 3.0 which comes with Windows Server 2012 R2. After the ADFS Plugin is installed the following additional "Mi-Token Authentication" entry appears in the ADFS Management Console: Ticking the "Extranet" and "Intranet" checkboxes in the Global Policy enforces Mi-Token Authentication for all applications configured to use ADFS for authentication. Alternatively these checkboxes can be left unticked in which case the similar checkboxes in the individual application policies (such as Exchange OWA policy or Exchange ECP policy) are not grayed/ disabled so it's possible to apply different settings to different policies. For example enable Mi-Token 2FA only for external (e.g. coming via AFDS proxy) OWA users, disable it for internal OWA users and enforce it for all ECP users.
AD LDS database
It is worth mentioning that most security guides consider a firewall to be the first line of defense only. Firewalls are affordable nowadays and used very widely yet the number of successful hacking attempts doesn’t dwindle to zero. So the security related software components behind the firewall play a crucial role and this certainly includes the database. Mi-Token doesn't use a conventional SQL compliant RDBMS for authentication decision making. It uses an AD LDS database which is powered by the same technology as Active Directory databases hosted by every domain controller. The AD/AD LDS databases are substantially more secure, there are no recent reports of a hacker being able to retrieve or change the data in an AD LDS database. This compares well to RDBMS where such events are more frequent with hacking techniques like SQL injection etc.
Reporting
Mi-Token Reporting is an optional component. It includes Graphical and Text Reporting. The former provides graphs reflecting high-level view of the system e.g. what was the histori cal up-time of each NPS server and who are the users accessing Mi-Token more frequently than others. The latter provides in-depths view into the system e.g. what property of which token has been modified and when did it happen. Reporting requires SQL Server 2008-2014 (any edition including Express) and stores very detailed history of Mi-Token usage thus making it available for future analysis, audits, advanced data mining etc. The database is not used by the authentication decision making components which do not even know it exists.
Mi-Token Solution Sales Deck
Mi-Token is designed to be a highly secure, cost effective, and
easily managed multi-factor authentication (MFA) Solution for the
Indian market.
Mi-Token MFA is highly scalable, secure, and compatible with most
VPN gateways, applications, and websites.
Mi-Token provides enhanced security by :
• integrating tightly with Windows and Active Directory (AD)
via plugins embedded directly into existing Windows
infrastructure
• eliminating the need for security patch updates (due to tight
integration with Windows)
• seamlessly integrating with Yubikeys, Crystal Tokens and
other tokens
• providing optional PIN security to all tokens, including Mi
Token’s free Soft Tokens.
Mi-Token provides unique and robust features for enhanced
security for the Indian market :
• Cached token support
• PIN security for every token
• Token management for all tokens – including Yubikeys
• Token management flexibility that enables support for more
complex token assignment in markets where:
1. multiple users utilize a single token.
2. Each user must be identified independently.
3. User log on/off information is mandatory.