Monday, 27 January 2020

How OTP codes are created when logging in with 2FA

When you are attempting to access an account, application, website or service that is protected by a one time password the required code is normally obtained in one of the following ways;
  1. The code is sent to your authenticating device (either via an SMS message, an email or possibly an automated phone call).
  2. The code is generated by an application (such as google authenticator) installed on one of your devices (mobile phone, laptop or computer).
  3. The code is generated by a self-contained hardware device (hardware token) that would normally displays the required code on an LCD display (some devices may act as keyboards and type the OTP into the field for you when a button is pressed, and other devices produce an audio equivalent for people with vision loss).
If the message is sent via SMS then the service provider will use an SMS service (such as Twilio) who will forward the message via a mobile network operator.
If the code is generated by an app, then the app would previously have received seed data via one of your messaging channels, and this seed data will be used to generate the code on the application. Using this method the service provider only sends data to you the one time (seed data), and this data is then used locally to generate the OTP.
If hardware tokens are used, then the OTP is generated by the token itself. The service provider does not need to send anything to the user as the tokens are normally pre-seeded (seed data would have been installed during manufacture, and the seed details would be passed to the service providers together with the tokens). Using this method the service providers pass on the means to generate the required OTP codes simply by passing to the required users the hardware tokens.

One-Time Password (OTP) and FIDO authentication comparison

When considering these two approaches you first need to appreciate how they differ, where each method is weakest, and then compare the level of difficulty an attacker would face in breaching each of these authentication methods. Both methods require a One-Time password to be entered during the logon process but differ in how the code is obtained by the user.

The SMS authentication method relies upon the required code being sent to the authorised users mobile phone via an SMS message - if the code is not sent to the authorised user, but to a device in the possession of someone attempting to hack into the account, then the method is compromised. Unfortunately the simplest (and most widely used) attack vector is for attackers to request a sim transfer (simply put the attacker persuades the phone company to transfer the users phone number to them and in doing so obtains all SMS messages sent to the user).

When using google authenticator this attack approach will not help an attacker as the code is generated on the user’s device via an installed app. As a result the attacker would need to either take control of the user’s phone (e.g. via a virus), or they would need to somehow obtain the seed data that is sent to the users device (before the app can be used data has to be sent to the mobile app, if the attacker either manages to get this data sent to them, or discovers the seed data from previous emails/SMS messages sent to the user), then once in possession of the seed data the attacker would be able to generate one-time passwords on an app installed on their own device.

From a hackers perspective intercepting the SMS messages (either by the sim-swap method or by hacking into the phone network itself) is generally a lot easier than obtaining the seed data as typically the seed data is only sent once to the user whereas using SMS messaging the codes are sent each time the user logs in.

As an alternative to both these methods hardware tokens could be used to produce the required one-time passwords. The advantage here is the hardware tokens are self-contained devices that the users would be in the possession of the authenticating user. They come pre-seeded, and no data is sent to the devices, so no interception is possible via a potential hacker (which greatly complicates any approach the attackers may take.

There is an attack vector that all 3 of the above methods may be vulnerable to - man in the middle attacks (and its variants). In these types of attack the user is tricked into providing their OTP codes to what they believe is the logon screen, but actually is passing the data to the attackers hardware directly. To protect against this type of attack you would probably switch from an OTP authentication approach and use a FIDO (or FIDO2) key instead.

So in answer to your original question, authentication methods based on SMS messages are probably the weakest in terms of security, with google authenticator being stronger, hardware tokens being stronger still and possibly FIDO keys being strongest overall (that being said even FIDO keys have their weaknesses - for example, most require you to physically connect the devices via USB connections which introduces different security weaknesses).

Thursday, 27 June 2019

2 step verification on Parallels RAS using SafeID

Parallels RAS (formerly 2X) is application virtualization software that delivers centrally-hosted Windows applications to local devices without the necessity of installing them.
With Parallels RAS, Windows applications can be used on devices that typically could not run them, including Mac & Linux computers, iOS & Android mobile devices, Google Chromebook think client and HTML5 web browser. 

Why Deepnet DualShield ?

Deepnet Security and Paralles have been technology partners for many years. Deepnet DualShield multi-factor authentication (MFA) component is natively built into the core of Parallels remote application server (RAS) by Parallels developers, providing strong multi-factor authentication to all Parallels RAS products with a native user interface and rich user experience. Although some other 3rd-party MFA products can be used with Parallels RAS via RADIUS, they simply can’t provide the same level of native & rich user experience and versatile MFA methods that Deepnet DualShield has delivered to the Paralles RAS users. This is why Deepnet DualShield is the de facto and most popular choice for Parallels RAS customers who need multi-factor authentication.

For more details see: Parallels RAS 2 Step Verification