Are you sure your mobile application is well protected? Is the business web platform or enterprise cloud system secure to the point of invulnerability? Do you still count on passwords as the sole authentication method or have you already moved to traditional 2FA?
This eBook will help you explore different ways to move to a more usable, cost-effective and secure model to protect your app or website.
SMS authentication is not an example of fully-fledged two-factor, but two-step.
Due to the ease of use and widespread distribution of mobile phones, it is very common for the second factor to come via SMS. Many have come across this, for example, when authenticating on a website.
The method is very simple: After a successful login and password input, the verification system generates a random code that is sent to the phone number via SMS. The user enters the received code into the form on the website or in the app and successfully passes the authentication stage.
In reality, however, there are many inexpensive types of attacks that allow the interception of an SMS with a one-time code or simply the re-releasing of a subscriber's SIM card by another person.
To protect users against reissuing of cards, some operators simply block the service of sending and receiving SMS for up to one day, and user authentication systems can detect a change in IMSI – the SIM card number – and not allow it to receive one-time codes before passing an additional stage.
One-time password generators are divided into:
Those that support open
Those that use proprietary algorithms for generating one-time passwords
The one-time password generator can be software (usually an application on a smartphone, such as Nexus TruID) or hardware (various key rings or plastic cards with a display such as a Display Card). Hardware generators surpass their software counterparts in terms of security as they are isolated devices accessible only physically.
According to the algorithms, OTP generators can be also divided into the following types:
A one-time password based on the counter of the number of previously generated one-time passwords. Example – OATH HOTP.
A one-time password based on the time slot – that is, the counter here is the number of steps, usually 30 seconds each. For algorithms of this type, it is important to synchronise the time of the authentication server and the generator. Example – OATH TOTP.
Request-response – the system generates a code that the client transfers to the OTP generator (using buttons, scanning a QR code, listening to an audio recording), where a one-time password is generated in response. This one-time password is entered by the client for authentication on the website or in the program. An example is OATH OCRA.
At first glance, it seems more secure to generate a password based on time, since the password has a lifespan. In reality, however, time is not a secret parameter and the attacker actually already has data about this part of the process. In addition, the legal owner of the OTP generator doesn’t recognise if the attacker has a duplicate generator. All authentication attempts — both user and intruder — will succeed.
If the counter password generation is used, a duplicate of the generator will be quickly detected, since the counter will be out of sync in the system and in the generator. It is also more difficult to guess the current position of the counter than to know the time.
The advantage of algorithms based on the request-response model is the possibility of mutual authentication of the server and the client, as well as the possibility of signing a transaction.
This method is based on asymmetric cryptography. The client has a private key with which he or she signs an authentication server request. The system can verify the electronic signature using the client’s public key (usually in the form of a certificate). This confirms the client’s ownership of the private key.
A private or, alternatively, a user's secret key can be kept on a smart card, a cryptographic token, or simply in a file on a disk or removable drive. The token, like a smart card, basically uses a cryptographic chip with non-recoverable memory. The private key is generated directly inside the chip and this key cannot be copied to another medium. Keeping the secret key in a file is less secure, since someone can simply make a copy of the file.
A considerable advantage of certificate authentication is the practical impossibility of compromising a cryptographic token in the foreseeable time using a limited budget.
If other verification methods require some secret information to be stored centrally on the server, then in the case of PKI authentication, the system doesn’t store or operate anything with secret information. The only thing the server needs is to know which Certificate Authority (CA) issues the certificates. It is simply not possible to leak any passwords or other secret parameters from the authentication server.
The Disadvantage of PKI
The low level of user convenience when working with tokens and cards for authentication, as well as the limitations of the devices to which you can connect a smart card or USB token, explain the rare distribution of this method.
Mobile authentication refers to the use of mobile devices, such as smartphones, to confirm entry.
A key pair is generated on the smartphone when registering with the system. The public key is sent to the authentication server, and the private key does not leave the smartphone and is used as in the usual certificate model.
The process of checking this factor usually occurs as follows:
This is one of the most promising two-factor methods. On the one hand, it does not require the cost of purchasing additional devices. On the other hand, it provides a high level of protection based on public key cryptography.
Moreover, mobile authentication is characterised by another advantage – the use of a separate logical channel.
An example of very successful implementation of this authentication method is Nexus Personal Mobile – an application that works in conjunction with the Hybrid Access Gateway server. In addition to authentication itself, the application allows you to sign transactions. A transaction information message is displayed on the smartphone screen before the user authorises it.
There are currently many biometric authentication systems available. As biometric characteristics of a person they use:
There are examples of centralised authentication systems by biometric parameters, but biometrics are mainly used for local authentication on the device: a laptop, a smartphone. Such systems allow you to exclude biometric data from the devices where they were collected and where they are checked.
Apps use these features to protect the input by replacing the PIN code. This does simplify user interaction.
Remember: Biometric authentication is based on the "similarity" of the current print, face, voice, etc. to the one that was studied by the system earlier. Small deviations from the sample present in the system will not lead to an authentication failure, in contrast to a small password change of even 1 character. That is, such a model cannot be called strict.
The FIDO Alliance is addressing the problem of authentication on the Internet and proposes the standard U2F (Universal Second Factor) – a two-factor authentication protocol.
This protocol allows the use of hardware cryptographic tokens but does not require complex centralised systems such as a single authentication server or public key infrastructure. This simplifies the application of the advantages of asymmetric cryptography and makes it accessible to a wide range of users and systems.
Among other things, the standard allows you to protect authentication processes from phishing and token cloning. Now such giants of the Internet industry as Google and Facebook allow its use.
It is necessary to strive for the unification of authentication subsystems in various automated systems. Ideally, the system is single, but depending on the criticality of the system or the actions performed by the user an additional factor(s) may be added to the system.
When it comes to the right choice of methods and devices for two-factor authentication, in particular software, it’s best to start with the analysis and prioritisation of the following criteria:
In addition to the authentication factors themselves, pay attention to the security of the technology itself.
Look for secure ways to transfer and store authentication data. Give preference to systems where use of the stored authentication data for registration in the system is not permitted and the intercepted data cannot be used for re-registration in the system.
It is clear that enterprises should continue to evolve and improve their user authentication, moving beyond the limitations of passwords and traditional 2FA. Absolutely reliable systems do not exist. However, the multi-factor model can bring considerable benefits to corporate software security.
We highly recommend taking the following steps:
Finally, it is never superfluous to assess the validity and security of your source code – contact the experts for consultation to make sure you’re well-protected on all counts.
If you have questions or need professional business consulting support, get in touch with our team and together we’ll discuss all the issues in detail. Contact Magora today: email@example.com