Townsend Security Data Privacy Blog

Taking Security Beyond Usernames and Passwords

Security professionals understand that passwords alone are just not good enough protection, and the on-going flood of data breach reports just confirms this on a daily basis. Enterprise IBM i users aren’t going to stop using passwords to login to their IBM i platforms, and hackers aren’t going to slow the flood of attacks any time soon. But now, we can take a giant security step forward by implementing two-factor authentication (2FA) to dramatically reduce the risk of a security breach.

Compromised email, social media, online gaming, ecommerce, financial services and other types of cracked accounts continue to threaten both personal and corporate interests. Out of all the threats that face individuals and companies, account compromise stands out as one of the most easily addressed with available and mature security technologies.

Historically, companies used physical tokens to provide authentication on the IBM i beyond username and password. Even if someone hacked a user’s password, they still could not login without the physical token. Tokens represent another layer of protection, which is a step in the right direction. Unfortunately, tokens increasingly do not make fiscal sense for Enterprise IT departments who have to deploy, manage, and troubleshoot large numbers of tokens. There is a better way for organizations to quickly and cost-effectively roll out two-factor authentication to a large and sometimes global user base. Solutions that leverage the mobile phone as a reliable means of authentication have become readily available for the IBM i platform. For example, instead of tokens, businesses can simply send an SMS or voice message that contains a one-time authentication code to the individual user’s phone. This means cyber criminals cannot log into the IBM i without physical control of the actual phone.

Mobile phones and landlines present key advantages for verification and authentication regimes:

• They possess unique identifiers – phone numbers, electronic identifiers and account numbers
• They remain in the possession of users or near at hand most of the time
• They are difficult to spoof
• If stolen or otherwise misappropriated, they are easy to disable
• Their association with actual individuals is verifiable through the operators that provide phone service

While none of these attributes alone are sufficient, together they provide a compelling basis for verification and authentication. The goal is to reduce fraud and actual theft of sensitive information by implementing something much harder to defeat than a login password. Combining something the person knows with something they have, or something they are, which can then be used for two factor authentication.

1. Something you know - a password. Even “strong” passwords can still be fairly weak from an attacker's point of view. With malware that easily detects them, passwords alone are a weak defense in relation to log-in security if that's all you have.

2.  Something you have - a mobile phone. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication.

3. Something you are – biometric authentication options.  Physically scanning for an iris pattern or fingerprint.

By using 2 of those 3 things you can authenticate more securely to the system.

Here are a couple examples of things that are not two factor authentication:

• Requiring two passwords: using one factor twice is not 2FA!
• Using shield questions of which are actually fairly easy in our social world to determine.

The IBM i platform has a well-earned reputation for security, but security is only as strong as the weakest point in the enterprise network. User PCs, internal and external web servers, and network applications represent points of attack. These systems are not safe from:

• Memory scraping
• Keyboard logging
• Stolen vendor credentials
• Stolen user passwords from external web services

Due to the nature and the extent of these security threats on the IBM i, two factor authentication has become a viable solution for meeting compliance regulations and safeguarding the vast amount of data and numbers of users with access to sensitive information on the IBM i. We're seeing Google, Facebook, Yahoo, and almost all large commercial banking websites implementing a two factor authentication system based on SMS text and or voice verification to give additional security to their users accounts and IBM i users now have an affordable solution for their platform. Find out more by downloading this white paper:

Because passwords can easily be compromised, they are considered to be a weak layer of security if used alone.

The use of two factor authentication (2FA) provides an added layer of security beyond just standard username and password credentials. Almost all connections to the IBM i platform are over a network (LAN or WAN), and they are rarely hardwired connections. Because networks are so susceptible to snooping attacks, even LAN connections should be treated like remote access. Remote access to networks containing critical payment, patient information, or financial records can be protected with two factor authentication using your mobile phone to receive SMS and voice verification authentication codes with an easy to deploy, cost effective 2FA solution for the IBM i platform!

Protecting access with two factor authentication adds identity assurance and significantly reduces risk of unauthorized access in industries covered by PCI DSS, HIPAA/HITECH, and GLBA/FFIEC compliance regulations.

• PCI DSS section 8.3 requires two factor authentication for remote access to systems containing credit card information.

• HIPAA/HITECH act recommends two factor authentication to mitigate the risk of lost or stolen personal health information.

• FFIEC guidance also calls for the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against a financial fraud.

Although there are varying levels of enforcement, it is clear that two factor authentication plays a growing and critical security role in both compliance and following best practices.

Since launching Alliance Two Factor Authentication in January, we have had a number of questions about the product and thought we would share them here (along with the answers!)

Q: Does Two Factor Authentication integrate into my already existing Single Sign On (SSO) environment?
A: Yes!  Because the authentication process takes place after the login is complete, it will help strengthen the security around SSO.

Q: In which countries is 2FA available?
A: Two Factor Authentication is a global product. We are partnered with Telesign, which has a network of over 120 countries and the ability to work with 90+ languages to support generation of SMS messages.

Q: What profile security is required to run 2FA?
A: As a native IBM i solution, you assign normal security controls during installation.  End-users have to have use-authority to the library to use the services.

Q: Does your 2FA solution require a mobile app (like Google does) to generate the authentication codes?
A: Since our solution is fully self-contained and installed on the IBM i platform, it does not require a mobile application. The 2FA solution talks over a secure connection to the Telesign service, resulting in a pincode delivered to your mobile device as a SMS text message, or to your standard phone as a voice message.

Q: What if I don’t have access to a phone?
A: In case you don't have a mobile phone, or are in a location where you can't get cell service, your IBM i system administrator can record up to four additional voice phone numbers per user. This gives you a lot of flexibility for putting in phone numbers for home, work, cell with either the text or voice option. In the rare chance you may be someplace without access to any type of phone, Alliance 2FA provides up to 5 one-time codes for use when the phone services are not available. These are randomly generated numeric PIN codes a user has access to, that gives them the ability to authenticate even if they don't have a phone with them at the time.

Developers are also able to improve the security posture of IBM i platforms at the application level as well as during the log-in process with Application Program Interfaces (API). Alliance Two Factor Authentication does full logging of authentication and configuration changes into the IBM security audit journal QAUDJRN. For anyone running our Alliance LogAgent solution to capture information from QAUDJRN into your SIEM solution or your log collection server, this will automatically integrate 2FA in that environment. Developers can use two factor authentication for certain critical functions in the application environment such as sensitive operations about patient information, specific financial transactions, critical system functions (like powering down the system or doing a restore) that you might want to protect with 2FA. We provide a complete API set to our IBM i customers so that they can use a simple structure to initiate a two factor authentication sequence within the application. IBM i web applications can use Java, RPG, or other web languages to call the APIs and fully implement web-based 2FA within the context of the IBM i system where our two factor authentication application is running. The APIs then return to the program the result of the two factor authentication request as either succeeded or failed, and you can take actions at the level of the application to record the event or to deny or allow a particular operation.  

For more information, request our 2FA Resource Kit!

If you have additional questions about 2FA, add a comment below… we would like to hear from you!  

Google is doing it.  Amazon is doing it, too.  Apple, Microsoft, Facebook, and Twitter have also been using it.  What is stopping you from deploying two factor authentication on your IBM i?

How do you stop a hacker who has just accessed a username and password that allows them *ALLOBJ authority on your IBM i?  Despite your best efforts at locking down user accounts, including enforcing complex and unique passwords, your most restricted credentials are now in the hands of hackers.
 
For companies who have deployed a two factor authentication solution on their IBM i, the situation is less dire.
 
While the IBM i is generally considered a very secure platform, it is still susceptible to hackers.  Most users access the IBM i via a PC, which are constantly being targeted with Malware.  Malware on a PC can easily capture usernames and passwords, send that information to a hacker, and in turn, open your systems up to a data breach.  Other points of attack include:

• Memory scraping
• Stolen vendor credentials
• Stolen user passwords from external web services

Fortunately, there is still a way to stop hackers who have your top credentials – with two factor authentication.  By requiring two of the following for their users, businesses can easily enhance their security in a cost-effective way:

• Something you know, such as a password
• Something you have, such as a phone or fob
• Something you are, such as a fingerprint

In Verizon’s “2014 Data Breach Investigations Report”, the company found that of the 63,437 total security incidents that occurred in 2013, “stronger passwords would help reduce the number of incidents, but larger organizations should also consider multiple factors to authenticate third-party and internal users.”  The report continued, “Two-factor authentication will help contain the widespread and unchallenged re-use of user accounts.”

Choosing a Two Factor Authentication Solution
Historically, companies used physical tokens (something you have) to provide authentication on the IBM i beyond username and password.  Unfortunately, tokens increasingly do not make fiscal sense for enterprise IT departments who have to deploy, manage, and troubleshoot these tokens.  Further, tokens are not foolproof as the recent attack on RSA proved.

Innovative solutions, such as Alliance Two Factor Authentication, that leverage the phone as a reliable means of out-of-band authentication have emerged. For example, instead of tokens, businesses can simply send an SMS or voice message containing a one-time authentication code to the IBM i user’s phone. This means cyber criminals cannot log into the IBM i without physical control of the actual phone.

Mobile-based two factor authentication solutions have become the preferred choice for businesses who don’t want the added expense of security tokens and the overhead of deploying and maintaining an appliance.  By deploying a two factor authentication solution on the IBM i, businesses can protect their critical data and operations, as well as their reputation, by adding an additional, cost-effective layer of security.

For more information, download the white paper Two Factor Authentication on the IBM i – Security Beyond Usernames and Passwords to learn more about why the IBM i may not be as secure as you think, the need for authentication on the IBM i, and how to meet compliance requirements with two factor authentication.

Two Factor Authentication (2FA) and a look at the compliance regulations that require identity verification for remote access.

The use of two factor authentication provides an added layer of security beyond just a username and password. Because passwords can be guessed, stolen, hacked, or given away, they are a weak layer of security if used alone. Since frequent access happens from outside of the network, remote login is considered high-risk and requires additional steps to confirm user identity. Protecting access with two factor authentication adds identity assurance and significantly reduces risk of unauthorized access in the retail, healthcare, and financial industries.

Payment Card Industry Data Security Standards (PCI DSS)

The PCI Security Standards Council has stated that they will continue to change and evolve compliance regulations over time as attacks change. In PCI DSS section 8.3 the requirement states that organizations must “incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.”  The objective of this requirement is to ensure that merchants implement strong access control measures so that authorized individuals with network and computer access can be identified, monitored, and traced.

Requirement 8: Assign a unique ID to each person with computer access. Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data.

Requirement 8.3: Incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.

Note: Two factor authentication requires that two of the three authentication methods (something you know - something you have - something you are) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two factor authentication.

Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act

HIPAA was an act signed in 1996 by President Bill Clinton, meant to improve the efficiency of the healthcare system by encouraging the use of Electronic Data Interchange (EDI) when accessing Protected Health Information (PHI). Covered entities must develop and implement policies and procedures for authorizing PHI access in accordance with the HIPAA Security Rule Administrative Safeguards 164.308(a)(4) [Information Access Management: Access Authorization] and Technical Safeguards 164.312(d) [Person or Entity Authentication] and the HIPAA Privacy Rule at §164.508 [Uses and disclosures for which an authorization is required].

The HIPAA Security Rule requirements have most recently been expanded via the HITECH Act, which establishes mandatory federal security breach reporting requirements with expanded criminal and civil penalties for non-compliance. To remain HIPAA compliant and avoid fines for HITECH Act non-compliance, strict control over access to patient records must be demonstrated.

HIPAA/HITECH requirements regarding the transmission of health-related information include adequate encryption [164.312(e)(2)(ii) when appropriate, and 164.312(a)(2)(iv)], authentication [164.312(d)] or unique user identification [164.312(a)(2)(i)] of communication partners. By selecting Two Factor Authentication (2FA), users would be required to combine something they know, something they have, or something they are; thereby providing more secure access to PHI files. Protected Health Information can be account numbers, medical record numbers and geographic indicators among other private consumer information. It is important that only those health care workforce members who have been trained and have proper authorization are granted access to PHI.

Gramm-Leach-Bliley Act (GLBA) & Federal Financial Institutions Examination Council (FFIEC)

The Federal Financial Institutions Examination Council (FFIEC) is charged with providing specific guidelines for evaluating financial institutions for GLBA (Gramm-Leach-Bliley Act) regulations compliance. The FFIEC also provides guidance around the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against financial fraud with the document, “Authentication in an Internet Banking Environment” (v.3). For banks offering internet-based financial services, the guidance document describes enhanced authentication methods that regulators expect banks to use when authenticating the identity of customers using online products and services, as follows:

• Financial institutions offering internet-based products and services to their customers should use effective methods to authenticate the identity of customers using those products and services. Furthermore, the FFIEC considers single-factor authentication (as the only control mechanism) to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.
• The implementation of appropriate authentication methodologies should start with an assessment of the risk posed by the institutions’ Internet banking systems. The authentication techniques employed by the financial institution should be appropriate to the risks associated with those products and services.
• Account fraud and identity theft are frequently the result of single-factor (e.g. ID/password) authentication exploitation.
• Where risk assessments indicate that the use of single factor authentication is inadequate, financial institutions should implement multi-factor authentication, layered security, or other controls reasonably calculated to mitigate those risks.

The FFIEC is a government agency which works with many other government agencies to unify how financial institutions should be supervised. The guideline documents recommend banks treat the FFIEC as baseline compliance for safe online authentication and transaction verification. Since all single factor authentication techniques can be easily compromised, financial institutions should not rely solely on any single control for authorizing high risk transactions, but rather institute a system of layered security with multi-factor authentication.

Although there are varying levels of enforcement, guidelines vs. laws vs. fines, it is clear that two factor authentication plays a critical security role in both compliance and following best practices. This trend will only grow within various industries and throughout the overall data security environment.

Townsend Security offers Easy to Deploy, Cost Effective Two Factor Authentication Solution for the IBM i Platform

Alliance Two Factor Authentication brings mobile SMS and voice verification to the IBM i platform. The solution was built to solve large scale problems in a cost-effective manner and appropriately addresses the concerns raised in the various guidelines and standards listed above. Remote access to networks containing critical payment, patient information, or financial records can be protected with the Alliance 2FA solution using your mobile phone to receive authentication codes.

For more information, request our 2FA Resource Kit! 

Two Factor Authentication (2FA) adds a critical layer of security to protect user accounts and prevent fraudulent access that goes beyond password logins.

Have you made time to watch our most recent webinar on Two Factor Authentication? If not, click here to learn more about how 2FA enables companies to increase their security without the high cost of hardware & software integration by using a technology that is already a part of every user’s life, offering a better user experience with little-to-no training required. Also by leveraging your mobile phone as an authentication device, Alliance Two Factor Authentication improves the security of user account access while reducing operating costs typically associated with traditional multi factor authentication methods.  

Here is a summary of the questions asked after the 2FA webinar:

Q: Does two factor authentication integrate into an already existing single sign-on environment?

A: Yes, you can deploy two factor authentication in a single sign-on environment. Alliance Two Factor Authentication runs natively on the IBM i platform, which allows you to use a SSO solution in the IBM i environment and still deploy two factor authentication to the end-user. We implement the second factor authentication on the IBM i platform, which means that we’re not linked to the actual SSO application that might be running on Windows or using an LDAP or active directory implementation. This provides you with better security for those users who are accessing your IBM i platform as it is not possible to then hijack the authentication requests in a PC environment.

Q: What company did you partner with to deliver 2FA messages?

A: Having customers all over the globe, we were very selective in choosing to partner with another company familiar with terms of network availability of two factor authentication. We chose the TeleSign Corporation. Their infrastructure has the ability to detect when SMS text messages may not be delivered, and they will fail-over to other options and take action in other routes. With guaranteed enterprise-level uptime and industry-leading deliverability rates, TeleSign has conducted more than 2.5 billion phone-based authentications and voice verifications around the globe.

Q: In which countries is two factor authentication available?

A: Our partner TeleSign has a strong, mature infrastructure in the European zone, Latin America, Asia, and delivers authentication codes to over 200 countries and that supports 87 languages. They are constantly testing network connections and performance and they've had time to build this very powerful global infrastructure for our Alliance Two Factor Authentication solution.

Q: How long does it take to deploy Alliance Two Factor Authentication?

A: We suggest you test drive our Alliance Two Factor Authentication solution which is available to download from our website. We typically turn around requests for an evaluation license very quickly and can have you up and running the same day. With our complimentary trial, we also provide TeleSign credentials so that customers can actually evaluate two factor authentication on their own systems. We provide you a fully functional 30-day evaluation, yet proof of concept for this application can be done very quickly.

Request your complimentary 30-day evaluation here

We look forward to hearing about how our 2FA solution works for you!

Defend your data by adding another step to your security process!

With increased losses of sensitive data from websites, retailers, and covered entities in the medical segment, we are hearing about data breaches on an almost daily basis now.  Are we as concerned as we should be, or are we getting jaded to the inevitability of data loss? When it seems like everyone is getting hacked, what kind of things can we do to help prevent access to our sensitive data?

After the recent Target data breach (and a number of other ‘holiday’ breaches), more information is surfacing on how attacks happen through unsecured websites, phishing emails, memory scraping, and keyboard logging malware that can get installed on individual user PCs. Once the hackers have usernames and passwords they can work their way through a network to where the sensitive information is stored.

For those of you on the IBM i platform, it might interesting to note that the IBM i is not immune from attacks and data loss. IBM i has a well-earned reputation as a secure platform, yet we are seeing keyboard logging attacks get past that great security as users log-in to the IBM i from their PC. IBM i platforms are typically great reservoirs of sensitive information; credit card numbers, social security numbers, personally identifiable information of all types make the IBM i platform a clear target for attackers.

In addition to the basics: encrypting your data and properly managing your encryption keys, you can immediately improve your security posture in relation to log-in security, as well as application level security by using two factor authentication (2FA) to prevent unauthorized access.  

The goal is to reduce fraud and actual theft of sensitive information by implementing something much harder to defeat. Combining something the person knows (password) with something they have, or something they are, which can then be used for two factor authentication.

• Something you know - a password

Security administrators can set system values for rules on passwords, require certain length passwords, characters and numbers, uppercase characters... but end-users are quite adept at creating passwords that can be easily remembered, yet meet the criteria of the strong password from the systems point of view. Even “strong” passwords can still be fairly weak from an attacker's point of view. With malware that easily detects them, passwords alone are a weak defense in relation to log-in security if that's all you have.

• Something you have - a mobile phone

Mobile phones that support SMS text or voice verification are something we all have and carry with us. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication. There are some immediate benefits to this technology:

• Companies don't have to buy expensive additional servers and hardware
• Users generally have a mobile phone already, and even if they replace their mobile phone, their phone number remains the same
• Reduced cost of administrative expenses

• Something you are - biometric authentication options (iris pattern or fingerprint)

By using 2 of those 3 things you can authenticate more securely to the system.

Here are a couple examples of things that are not two factor authentication:

• Requiring two passwords: using one factor twice is not 2FA!
• Using shield questions of which are actually fairly easy in our social world to determine (Just the other day I received a message on a social media site that said “Hey!  We might be related… what is your mother’s maiden name?”)

We're seeing Google, Facebook, Yahoo, and almost all large commercial banking websites implementing a two factor authentication system based on SMS text and or voice verification to give additional security to their users accounts.

Cell phones that support SMS text or voice verification are something we all have and carry with us. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication. There are some immediate benefits to this technology:

Earlier this year we introduced Alliance Two Factor Authentication for the IBM i, which fully implements 2FA using SMS text or a voice verification call to your mobile phone.  In case you don't have a mobile phone, or are in a location where you can't get cell service, we allow the user or system administrator to record up to five mobile and voice phone numbers per user. This gives you a lot of flexibility for putting in phone numbers for home, work, cell with either the text or voice option. In the rare chance you may be someplace without access to any type of phone, Alliance Two Factor Authentication provides up to 5 one-time codes for use when the phone services are not available. These are randomly generated numeric PIN codes a user has access to, that gives them the ability to authenticate even if they don't have a phone with them at the time.

Developers are also able to improve the security posture of IBM i platforms at the application level as well as during the log-in process with Application Program Interfaces (API). Alliance Two Factor Authentication does full logging of authentication and changes to the configuration files into the IBM security audit journal QAUDJRN. For anyone running our Alliance LogAgent solution to capture information from QAUDJRN into your SEIM solution or your log collection server, this will automatically integrate 2FA in that environment. Developers can use two factor authentication for certain critical functions in the application environment such as sensitive operations about patient information, specific financial transactions, critical system functions (like powering down the system or doing a restore) that you might want to protect with 2FA. We provide a complete API set to our IBM i customers so that they can use a simple application program interface (API) structure to initiate a two factor authentication sequence within the application. IBM i web applications can use Java, RPG, or other web languages to call the APIs and fully implement web-based 2FA within the context of the IBM i system where our two factor authentication application is running. The APIs then return to the program the result of the two factor authentication request as either succeeded or failed, and you can take actions at the level of the application to record the event or to deny or allow a particular operation.

For a more in depth technical discussion, please check out this great webinar on two factor authentication by security expert Patrick Townsend:

Because usernames and passwords are no longer good enough!

To protect sensitive data, businesses need another layer of security and are often turning to two factor authentication (2FA). Most of us are now familiar with online banking websites that implement 2FA; after you put in your username and password, you get a text or a voice call with a pin code to enter, in order to authenticate yourself. Two factor authentication is a well recognized method of strengthening the authentication of the user and improving the security of access to mission-critical systems. 2FA is described as taking “something you know” (your username and password), and adding “something you have” (a hardware token, ATM card, or mobile phone), or it can even be “something you are” with expensive biometric (fingerprint or retina) scans, to strengthen your security defenses.

In today's world you have to be aware that system attacks can be very intelligent. For example, a user on a PC can open up a document or PDF file and their PC can become infected with malware that does keyboard logging when they remotely log in to the IBM i. When this type of attack happens, the keyboard logging software collects user IDs and passwords and then someone uses this information to access networks beyond that PC. The IBM i platform has a well-deserved reputation for being a good solid secure platform, yet it is just as susceptible to a keyboard logging attack as any other platform. Two factor authentication is really designed to help prevent this type of malicious access, where an attack is initiated outside of the IBM i platform by using credentials that are already known to the attacker. In traditional IBM i shops, when a user logs in to the IBM i platform they provide their user ID and a password, that single factor password is “something you know”, and would get access to the system. There are a lot of system values that a security administrator can set to enforce the use of strong passwords, but adding a mobile text or voice message with a pin code (adding “something you have”) to the mix is one example of how a two factor authentication can really help strengthen the security of the IBM i platform.  Hardware tokens such as key fobs or even ATM cards have been a traditional means of 2FA, but can be costly and time-consuming  to generate (and replace) in comparison to using SMS or voice messaging via mobile phone.

By deploying a 2FA solution, organizations can easily enhance their security in a cost effective way, as well as meet compliance regulations:

• PCI Security Standards Council has said they will continue to change and evolve compliance regulations over time as the attacks change. PCI DSS section 8.3 requires two factor authentication for remote access to systems (almost all connections to the IBM i platform are over a network, they are not generally hardwired connections or network connected devices).

• HIPAA/HITECH act recommends two factor authentication to mitigate the risk of lost or stolen logons or passwords.

• FFIEC guidance also calls out the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against a financial fraud.

In the past deploying a 2FA solution on the IBM i has been costly and complex.  Townsend Securitys new Alliance Two Factor Authentication product is taking a different approach and implementing a solution that is very cost-effective on the IBM i platform. Leveraging mobile phones, the cell phones that users already carry, our new solution is strictly a software implementation. There are no expensive administrative access controls, hardware servers or hardware tokens that users carry around with them, and we think this helps control the cost. You won't incur the expense of replacing tokens and reprogramming them, it's a very straightforward install, software only solution that talks over the Internet to the SMS text or voice delivery gateway with our partner Telesign. Telesign has quite a mature implementation and infrastructure, able to deliver authentication of messages to over 200 countries in the over 80 languages worldwide. With over 2 1/2 billion accounts active today, we found them to be a great partner in bringing mobile and text-based two factor authentication to our customers on the IBM i platform.

We are pretty excited about our new “no hardware, no hardware tokens, strictly a software implementation” Alliance Two Factor Authentication solution.  Please download our latest podcast to hear more about:

• Different methods for two factor authentication with their pros and cons
• How businesses can meet compliance requirements with 2FA
• Ways 2FA is helping organizations to improve the security of their core business applications
• How we provide a full set of APIs that IBM i developers can use to enable application controls using two factor authentication
• How you can still get the benefits of two factor authentication if you are out of cell range
• And a number of additional security features built into the product...