Two-Factor Solutions Choosing the Right One"

Transcription

1 Copyright (c) 2013 RCDevs S.A. ( - Page 1/ Two-Factor Solutions Choosing the Right One By RCDevs ( The need to secure access to online applications and resources is increasing every day. This is the result of the business evolution where companies tend to have their staff work from remote locations, use mobile devices and deploy their corporate or external services on the cloud. In this context, it is important that employees, customers and collaborators get strongly identified and authenticated when accessing sensitive systems and data. There are many ways to increase the security level for external access systems but we will focus on the user authentication and in particular on the Two-Factor technologies (2FA) using One-Time Passwords (OTP). This article will not discuss the pros and cons of available solutions nor the costs involved in the deployment of such solutions. In fact, there are many resources on the Web discussing these topics already. Instead, we will focus on the OTP technology itself and see what are the criteria ensuring an OTP technology is really secure in its different contexts of application. This is an important point because many companies choose a technology based on a simple cost estimation and few general criteria. Moreover choosing a security solution is not an easy task as there are many solution providers on the market. These solutions are all promising to be the best one and come with more and more extra features. But in practice, not all of them provide the same level of security; as an example, many solutions propose a bunch of features and token devices to convince you, but this does not means the proposed features are the best choice when considered individually. If you plan to implement two-factor security, there are important points to be checked. But not everyone is a security specialist able to evaluate by himself the technological aspects. And as you certainly know, enterprise security is one of the particular domains where you cannot simply compare the commercial catalogs for common functionalities and requirements. This article will also provide you some technology explanations and the minimal knowledge required for choosing the right solution. 1. What is Two-Factor and OTP? Two-Factor means a certain security level in the authentication process where the end-users log in with credentials being the combination of something they know (typically a username and password) and something they have (typically an OTP token). The security of the user access is guarantied by the fact that without one of these two information, the users cannot login.

2 Copyright (c) 2013 RCDevs S.A. ( - Page 2/ The One-Time Password is a simple concept which provides the something that you have part of the authentication process. It is a password which changes at every usage or is valid for a very short time. The OTP is also not something you can know in advance but something that is provided by an additional hardware or software which you carry with you for logging in. The OTP mechanism is not something new and has been already used for decades. The most popular technology is the RSA SecureID. Today there exist many hardware vendors which provide OTP tokens. And with the Initiative for Open Authentication (OATH), all vendors tend to implement the OATH open algorithms for more hardware and software interoperability. An OATH token deliver an OTP code automatically (every n seconds) or on demand by pressing a button. The OATH supports three token families: The event-based tokens (HOTP), the time-based tokens (TOTP) and the challenge-based tokens (OCRA). Some vendors provide alternative token solutions such as Yubico with the YubiKey. The YubiKey does not display an OTP on a LCD screen. Instead, it is an USB stick which injects the OTP code directly to the password input when it plugged-in and pressed. Another way to deliver an OTP to the user is to use an out-of-band mechanism such as sending the OTP to the user mobile via SMS or sending the OTP via . There are also some derived solutions which rely on the OTP mechanisms but propose another user experience. An example is the QR Code login provided by TiQR or Google. 2. Why is OTP well suited for 2FA? At the time of this writing, people should implement strong authentication for any external or exposed system. In the domain of user authentication, OTP is not the only technology to be considered and there exist alternatives such as PKI with client certificates or even biometry. But OTP remains the most interoperable choice for standard requirements. It is also the simplest and most cost-effective way to implement strong authentication. And if you need to secure several heterogenous systems, OTP is most of the time guarantied to work with your systems at minimal integration costs. OTP is more interoperable for a very simple reason: From the point of view of the authenticating system, the OTP remains a password. And most existing systems requiring a user login still work with usernames and passwords. This is applicable to VPNs, Web applications and any standardized protocol such as SSH, FTP, SMTP, POP, IMAP, etc... Some people might say OTPs are outdated and today s authentication systems should implement newer technologies (mobile PUSH, electronic signatures, etc...). This is a good approach but it is simply not applicable to most of the systems and protocols in use in the real world. A practical example is the VPN servers where the common protocol used to implement remote user authentication is RADIUS. RADIUS can only transports classic credentials and also needs usernames and passwords. PKI-based authentication is very powerful in the sense that is relies on the strongest mechanism which is the electronic signature with public and private keys. But its usage is limited to some specific applications because the technology requires hardware or software directly connected to the user computers. This is required because unlike the OTP which is a code composed of few digits, the electronic signature is a much longer data which cannot be handled manually. It

3 Copyright (c) 2013 RCDevs S.A. ( - Page 3/ is well suited for banking access from home computers but not for accessing the company systems from your tablet PC. Biometry is very interesting because it provides a convenient way to get the user identity. Yet biometric systems do not replace passwords; your biometric identity (i.e. your fingerprint or facial recognition) is basically a static data which is comparable to the username part of your login credentials. Also a efficient and secure way of authenticating users with biometry is to get the user identity via a facial recognition and require an OTP. 3. Technical evaluation of an OTP solution Now that we presented the OTP concept, let s discuss some important points to be foreseen when evaluating and choosing an OTP technology. Depending on the level of security required, the authentication methods to be implemented, the following aspects should be reviewed carefully Secure server storage Any synchronous OTP authentication system like tokens and YubiKey work nearly the same way: the token device or software token application includes a shared secret key (the token seed) and a dynamic state (the event counter or the current timestamp). The OTP code is calculated based on a mathematical function using these metadata. To be able to validate an OTP, the authentication server must also store a copy of the secret key and the state value for each user and token. A particular attention should be given to the storage of these metadata on the OTP server. OTP systems generally stores the token metadata in an SQL or LDAP database. In any cases, the metadata must be stored in an encrypted form and in such a way that even if someone can access and read the SQL or LDAP data, there is no way to extract the original metadata from it. The server must also enforce a robust secure data protection, implemented through strong encryption cyphers to handle user metadata encryption/decryption. Alternatively, it may rely on an Hardware Security Module (HSM). This is the strongest but most expensive option Combined PIN and OTP passwords An OTP authentication system should provides the user authentication with OTP and also with combined PIN+OTP; the PIN being a static password such as your Active Directory password. Relying on a username and an OTP password is stronger than using static passwords because the OTP password changes for every login. But on the other side, the OTP password is generally shorter and only composed of digits (typically 6-8 digits with OATH). Without a proper user blocking protection, we can also consider an OTP password is more sensitive to bruteforce attacks than a static password with a good password policy. For example, with OATH HOTP and an HOTP look-ahead window set to 10 OTPs, each individual login attempt has 10/ = 1/ chances to succeed. Requiring both the static password (PIN) and the OTP as part of the authentication process increases a lot your security level. For example, even with a short PIN of 4 character and an OTP of 6 digits, the changes of finding a good combination would be 1/ Yet, this is true at the condition that the system checks both passwords but never tells what

4 Copyright (c) 2013 RCDevs S.A. ( - Page 4/ password is wrong. Let s take as example an SMS OTP system which first asks for your static PIN and then prompts for the SMS OTP. A typical Web login form will asks for the username and password (i.e. the PIN). The user enters the information, receives an SMS OTP and is prompted for the OTP with an on-screen challenge message (ex. Please enter your OTP: ). The PIN password has two advantages in this scenario: 1) no SMS will be sent if the PIN was wrong. This protects the user from SMS spamming and unexpected SMS costs when someone else tries to login. And 2) both passwords are required which greatly increases the strength of the login process. But in practice the strength of the combined passwords is not the same if the systems fails immediately after a wrong PIN is entered or if it behaves the same way after good/wrong PIN, then prompts the OTP and fails at the end without telling whether the PIN was wrong or the OTP was wrong. Of course in the later case, the system will not send the SMS if the PIN was wrong. It will just behave the same way with the good/wrong PINs and fail at the end of the authentication process not to let the attacker know what password was wrong. This principle applies to any OTP system working with PINs and challenged mode (in two steps). It is due to the fact that if one manages to hack the static PIN, the security is then diminished to the protection of the OTP alone. Systems where the PIN and OTP are provided at the same time are also not affected. For example, many systems support concatenated passwords where the user enters both PIN and OTP passwords in the same input field. Also systems which first check the OTP and then the PIN are not affected. Another interesting protection is to prepend the OTP codes with a static PIN code. Unlike the user password PIN described previously this prefix code is part of the OTP and not a secondary authentication factor. For extreme security, prepending the OTP with a PIN code can be used commonly with the static password. With the SMS authentication of our previous example, two modes might be supported: ondemand and prefetch OTP delivery. With on-demand, the SMS OTP is send immediately after the username and PIN are provided. And with prefetch mode, the next SMS is sent after an authentication is completed. With on-demand SMS, a challenge mechanism is always required and using concatenated passwords is not possible. Anyway, in both modes, challenged OTP is generally preferred and is more user friendly than combined passwords Authentication transaction locking A strong OTP system should prevent two authentication transactions to be started simultaneously for the same user. Or at least the OTP verification step and token state update in the token store must be handled under a locking system preventing concurrent operations. More generally, a valid OTP must not be re-usable whether it is an event-based OTP, a time-based OTP or any other. Without such an internal locking system, an OTP may be used twice (in two authentication process started concurrently for the same user). When challenge is used, an authentication session is initiated on the system and a challenge response is returned to the authenticating system (with a user prompt message). The user has to provide the requested information (i.e. the OTP) within the time limit of the challenge session. But what happens when the user starts a second authentication session or closes the first one by mistake (without responding the challenge) and starts another one. Some systems will

5 Copyright (c) 2013 RCDevs S.A. ( - Page 5/ prevent the user from starting the second session while the first one is still opened whereas other systems will create a second session overriding the first one. This second option is better from the point of view of the user which never has to wait 1-2 minutes for the challenge session timeout in such situations. Yet, this convenience is at the expense of security: Let s take as an example, a user (Alex) authenticating with a username and an event-based token in challenge mode. Alex enters his username and password and receives a challenge asking for his OTP. Now lets imagine user Bob is behind Alex and has seen the username and OTP or is able to capture the OTP from the network. Bob starts an authentication just after Alex, using Alex username and enters the challenge response (the OTP) before Alex. The OTP being an event-based code, it is valid for both Alex and Bob and without a proper protection, the first to provide the OTP or the last started session will succeed. Preventing the second session (for user Bob) to be started when Alex session is started also provide the advantage that Alex OTP cannot be used by Bob while Alex is authenticating even if the login credentials have been captured from the network. If the OTP is good, then it not usable anymore after Alex authentication ended. And if it s wrong, then it s useless for Bob. When a cluster of authentication servers is deployed, the transaction locking mechanism should be implemented at the cluster level and not only at the server level. We will discuss it a bit later Blocking policies The user blocking policy is an important point to be considered with authentication systems. The OTP mechanism provides the credential-level strength and the blocking policy determines how the system will be resistant to brut-force attacks. Let s take as an example a system protected with an OTP (without PIN). Without additional protection, the attacker has for example 1/ chances to find a good OTP per login request. The blocking policy will block the login attempts after n failed logins either permanently or for a configured period, preventing many retries. A complementary protection to the user blocking is to include a short blocking timer after each failed login to reject requests for the same user without processing them. This other protection will implement a minimum retry delay and may also protect the system from DOS attacks Multiple tokens per-user This is a common requirement to be able to assign and enable several tokens for a single user. For example, the user may have a home token and an office token. Or the user may have an hardware token and a mobile software token. This is a powerful functionality but it must be used carefully. The main reason is that the more you enable concurrent tokens, the more you decrease the security of OTP codes. Let s imagine up to 10 OATH HOTP tokens are enabled for a user. Now let s say the HOTP tokens have a look-ahead window of 10 OTPs and an OTP length of 6 digits. Each token may also accept 10 codes at a time making a total of 100 valid codes per user at a time. The chances of finding a good OTP is 100/ so 1/ As you can see in our example, each additional token reduces by a factor of 10 the security of the OTP system and the OTP strength is not acceptable anymore. The same principle applies to time-base tokens. For example, you use OATH TOTP tokens and you accept a clock drift of max 2.5 mins forward and backward between the server and the

6 Copyright (c) 2013 RCDevs S.A. ( - Page 6/ Token. With 10 valid tokens, the chances of finding a good OTP is also 100/ so 1/ Now if your HOTP token are configured with a look-ahead window of 20 OTPs or your TOTP tokens allow a clock drift of 5 mins, this chances of finding a good OTP goes as high as 1/ A system implementing multiple concurrent tokens must prevent users from enabling many tokens at a time. A good balance between security and flexibility is to allow a maximum of 2 or 3 concurrent tokens for a user. If more tokens per user are required, concurrent tokens is not the solution. A workable solution is to asks the user which of his tokens he want to use as part of the authentication process. For example, the has to enter the OTP in the form <TokenID>:<OTP> and the system will validate the OTP for specified token only. Another reason why enabling multiple tokens reduces security is simply because the more the users have tokens in their hands, the less they will take care of each of them individually. If a user looses or is stollen one of his tokens, there are chances he will not even notice it or too late. And if he does, he will not prioritize the blocking/renewal of this specific token because he is still able to authenticate with the remaining ones. When an additional token is required for backup (non business blocking) purposes, a good approach is to have a primary token and a secondary unactivated token. In case the user cannot use his primary token, he may contact the help-desk or use a self-service portal to temporarily activate the secondary token instead of the primary one. Or you may temporarily configure the user authentication with another method like SMS OTP Software tokens vs hardware tokens vs SMS OTP authentication systems generally propose hardware tokens, software tokens and out-ofbad authentication. It is generally considered that: - Hardware tokens provides the best protection at the expense or additional cost and more maintenance. - Software tokens are more convenient but less secure than hardware tokens because they rely on the mobile phone OS and storage. - Out-of-band SMS is less reliable because it uses the mobile operator services. It offers a good level of security as the channel used for authenticating and the channel used for transmitting the OTP are different. Hardware tokens are always preferred for highly secured systems because the sensitive token metadata (i.e. The secret seed and token state) is not extractible from the hardware. The software tokens store these information in the application datastore on the phone. The seed protection also depends on the security level provided by the OS for storing these data. Yet, some other factors must be considered: - Soft tokens can be protected with a PIN code whereas hardware tokens have no keypad and display the OTP by pressing a button.

7 Copyright (c) 2013 RCDevs S.A. ( - Page 7/ - Usual software token applications are able to register multiple independent token instances whereas a hardware token is generally bound to one service provider. - Users will most of the time notice they lost or were stolen their mobile phone after minutes whereas they will realize they lost their token only the next time they will need to use it. Provisioning and maintaining large amounts of hardware tokens may also introduces big overheads and non-negligible extra costs. Software tokens have the advantage that you do not need to deliver nor exchange any hardware for the users. And many OTP solution vendors provide some self-service applications for software token enrollment and resynchronization. Out-of-band authentication is becoming more and more popular because it can use a device the users already have (their mobile phone) and it does not require any specific enrollment process. The initial deployment of an SMS-based solution is also very simple compared to tokens. Yet, relying on services of mobile operators with SMS roaming and SMS delivery delays is by far not as reliable as a token-based solution. And in most scenarios, companies will require a dual authentication system with SMS and software token as fallback. An efficient authentication solution will provide this backup functionality and will accept both the SMS OTP and the token OTP at the same time. If the user has no mobile coverage of does not receive the SMS OTP immediately, he can still use his mobile token. The security of SMS OTP comes from the fact that the OTP is sent via another communication channel than the one used for login in. An attacker would also have to hack both the GSM and computer network channels used by the user at the same time. Yet, it must be considered that mobile phones and their SMS store have never been made for storing sensitive data. For example most smartphones rely on a cleartext sqlite database to store the SMS messages. The OTP received on the mobile is also not stored securely and this is particularly important when authentication systems use the prefetched OTPs. In this case, the next OTP is received after the last login and until the next authentication which can be in 10 days Clustering considerations Clustering and especially failover is a an important aspect when dealing with central infrastructure components such as authentication systems. If many access to your company resources rely on the OTP, then you must setup your authentication infrastructure with a minimum level of redundancy. Most OTP systems work with an SQL database and/or an LDAP directory as back-end and can be deployed in cluster mode where every server is connected to same DB and LDAP. But not all of these systems are able to ensure cluster consistency at the transaction and session level. By consistency we means the distribution and the locking of user transactions and sessions across all the cluster nodes. This point is mitigated when the cluster nodes are never used concurrently but it becomes mandatory in the following scenarios: - More than one authentication server are used concurrently in some circumstances. - Authentication request are distributed randomly to the servers (load-balanced cluster).

8 Copyright (c) 2013 RCDevs S.A. ( - Page 8/ - Multiple servers are deployed which use the same user and token store(s) (DB/LDAP). For example you have several sites, each site using its local server(s) but using the same users with the same DB/LDAP stores. In these scenarios and without a proper cluster support implementing distributed transaction locks and shared sessions, the OTP system may be subject to replay attacks and user data inconsistencies. To illustrate the replay attack, let s say user Alex logs in on company Site A with his event-based token. And at the same time, he logs in on company Site B with the same OTP. The OTP code will be successfully validated on both sides but it should have worked only once. The same principle is applicable to the distribution of any work data across the OTP cluster, including challenge sessions, user blocking states, etc Replay attacks A typical attack affecting OTP authentication systems is the replay attack where it becomes possible to re-use the same OTP code two or more times. An OTP system must also be resistant to OTP replay. Let s go through the replay issues for the different OTP mechanisms. Event-based tokens (ex. OATH HOTP and YubiKey) An event-based tokens generates a new code on-demand. It must also permanently stores a token state or event counter. On the OTP server, the token code validation and the counter increment must be performed under a transaction lock to ensure the same OTP cannot the used in two simultaneous logins. Time-based tokens (ex. OATH TOTP) A time-based token does not need to store a state value as in this case the state is the current timestamp. Yet, one OTP code is valid for an amount of time (ex. 30 seconds) and if you allow some clock drift, this timeframe is several minutes. In order to prevent OTP replays, it must not possible to re-use the OTP within this timeframe. The OTP server must also store the timestamp of the last OTP to prevent any code generated up to this time to be validated twice. Moreover, like with the event-based tokens the server must validate the OTP and store the last timestamp under a transaction lock to ensure the same OTP cannot the used in two simultaneous logins. Challenge-based tokens (ex. OATH OCRA) With challenge-based tokens, the generated OTP depends on a random challenge code which is provided by the server at each new login. As the random challenge is specific to one authentication session, these tokens are also not affected by the replay issues of HOTP and TOTP. Yet the server challenge may be insufficient in terms of randomness and using an additional moving factor (i.e. a timestamp, an event counter or a session ID) should be used in the OTP calculation. Without this additional factor, the same challenge would always produce the same OTP. This problem becomes critical when the challenge length is for example four digits. In this case and without the second moving factor, the token is only able to issue different OTPs.

9 Copyright (c) 2013 RCDevs S.A. ( - Page 9/ 3.9. Connected tokens Some solutions propose alternative authentication systems which use the mobile phone capabilities (data network connectivity, mobile push or even camera) to transport authentication data. These data channels may be used 1) to transport the authentication requests to the mobile token and/or 2) to transport the authentication responses (OTP or electronic signature) to the OTP server. There are several solutions to transport an authentication requests to the mobile tokens: - Server connection : The mobile token opens a permanent connection the OTP server on its public IP address. - Mobile Push : The OTP server sends a push notification to the mobile token. This requires an IP connection too. - NFC communication : The mobile token receives the OTP request wirelessly via a near-field communication. - QR Codes : The mobile tokens is able to scan the authentication request displayed via a QR Code on the computer screen. And there are not many ways to transport the authentication responses to the OTP server: The mobile token has to contact the OTP server on its network address over Wifi or 3G. Sending authentication requests over the IP network or via the mobile push API both transport data over the IP network. With server connection, the mobile token must pre-establish a permanent connection with the OTP server in order to be contacted later. Whereas with push, the mobile just needs to be connected to the network to be able to receive push notifications. Note that none of these systems work when the mobile phone has no network coverage. QR Code authentication do not use the network communication channels. Instead, the mobile tokens reads the authentication request on the computer screen. This also much more reliable than IP and push communications. Then comes the problem of returning the authentication responses (OTP or electronic signature) to the OTP server. At first look, an electronic signature seems to be a better choice because it offers a stronger authentication than an OTP. Yet an RSA/ECC signature is much longer then an OTP (ex. 1024/2048 bits for RSA) and if the token has no network coverage, there is no other way to return this very long data manually to the server. With an OTP (ex: an OATH OCRA response), the token may optionally display the 6-8 digits OTP code for a manual authentication if it was not able to automatically send the response via the network. In this context of availability we can also consider an OTP is more reliable than an electronic signature. Some vendors propose a push-based authentication where the login request is displayed on the mobile token. The user optionally enters a PIN and clicks a button to confirm the access. It is

10 Copyright (c) 2013 RCDevs S.A. ( - Page 10/ very convenient but requires the mobile network connectivity, and because of restrictions with push APIs, it uses un-guarantied cloud-based push services for Android, IOS, etc... Some other vendors propose QRCode authentication with OATH challenge-based OTP. The OTP is returned via the IP network or manually when there is no network coverage. This alternative remains very handy for the user, fully secure and is still workable even with no network connectivity. We ve just discussed the pros and cons of connected tokens at the communication level. But another important point has to be discussed which affect the security of the authentication process: As a general rule, a connected token should never work without a manual or scanned user input and in particular without a session context data exchange between the user computer and the token. Because without it, there is no insurance the computer login session is linked to the token request. Let s take an example: User Alex logs in a web page and enters his username. At the same moment, user Bob who is at the office behind and has seen Alex is connecting, goes to the login page, enters Alex s usename and clicks the login button just before Alex. Alex receives a push-based authentication request on his mobile token. The request informations are correct and Alex confirms the access. Here Alex has confirmed Bob s authentication session. Bob gets authenticated using Alex account and Alex is not authenticated. To avoid this situation, the login page should display an ID to be entered on the mobile token or the token should display an ID to be entered on the login page. This ID would ensure the token login request corresponds to the computer login session. Of course, the login page and the token may display an ID to be verified by the user during login. But in practice, the user will not always verify the ID matches and will not even understand the meaning if it. A manual input of a short ID as also required to secure the authentication process. QR login is not affected by this problem because the ID is passed from the login page to the token via the QR code itself. There is also no need for another manual input Cloud service or integrated software Cloud-based services gain in popularity as many security vendors tend to provide the authentication facilities via remotely hosted services. This is very attractive for customers who see here a way to abstract the complexity of the authentication systems and reduce their solution and deployment costs. Yet, there are some aspects which need to be analysed in order to choose between a corporate or a cloud solution: - The authentication data whig are transported from your company to the external services go across many public (untrusted) networks and you can never know nor control what is in the middle. Communications may be secured with SSL two-way but even then, you don t know at what level the SSL endpoint stops on the remote side and what other networks and systems are left behind. With a local implementation, you alway have the full control over your infrastructure. - An authentication service may require to be connected to your corporate LDAP and access or replicate the user information. Do you want and are you allowed to send these sensitive/ personal data to a service provider especially when it is located in another country?

11 Copyright (c) 2013 RCDevs S.A. ( - Page 11/ - An authentication service is used by many companies other than yours and the APIs are generally publicly accessible on the Internet. These online services make good candidates for hackers and the service you rely on may be under attack simply because someone else is targeted. Online services might be more sensitive to DOS attacks too. - Access systems and in particular user authentication is a central and critical point of your corporate security. If you externalize the authentication, you must be 100% sure you can trust the infrastructure, operations and staff behind the cloud services. You define and enforce some security procedures and policies for your own security administrators and staff. You also have to verify that the same level of procedures and staff clearance is enforced for your externalized services. - The authentication systems are critical because they may be blocking or impacting your business in case of unavailability. The cloud services must also be implemented in such a way that it is as reliable as your internal services. Externalized systems mean new potential points of failure. What happens if the remote service is unavailable due to network problems? - Externalizing the authentication looks interesting to optimizing the costs and maintenance. But after few years you may realize it costs even more than an efficient local implementation. Remote services require additional connectors, replications, connectivity and never means less integration efforts for connecting your VPNs and applications. Depending on your size, you may also need to deploy thousands of users to the remote systems, batch modify them etc... Cloud services will provide Web-based remote interfaces with import tools etc... But will you be able to run custom tools and scripts? Can you prototype, test, duplicate, backup like in your local environment. - The infrastructure costs impact for a local implementation is mitigated because most companies use virtualization. You can also virtualize the security infrastructure but of course your software maintenance will remain. Conclusion We went around few technical aspects of typical OTP solutions. We ve also seen that aside the basic functionalities, some technical criteria should be analysed as they have important an impact on the strength of your security implementation. Of course there are many other parameters to be considered in your process of choosing the right OTP solution. And the technical aspect is just a part of it. But the intend of this short article is only to provide you with a technical overview or some deeper knowledge around the underlying technologies. We also hope these information will help you approach two-factor security concerns with the real questions and a more critical viewpoint. You can contact RCDevs at info@rcdevs.com if you need further information.

12 Copyright (c) 2013 RCDevs S.A. ( - Page / About RCDevs This article has been written by RCDevs S.A. ( RCDevs is an award winning security company specialized in next-generation two-factor authentication. RCDevs is building its growing reputation over high-quality security software and its customers entire satisfaction. RCDevs provides cutting-edge enterprise-grade solutions in more that 30 countries to customers ranging from SMEs to large corporations in the IT, financial, healthcare and government sectors. RCDevs is the developer of OpenOTP Authentication Server ( openotp/) and TiQR QRCode Authentication Server ( RCDevs OpenOTP and TiQR Authentication Server received the Highly Commended Award for the Best SME Security Solution at SC Magazine Awards 20 Europe and won the Sesames Innovation Awards 20.