About two-factor authentication

On SURFsara compute and storage facilities we will move away from the traditional username + password combination for authentication, in favour of stronger procedures such as certificate-based identities and two-factor authentication (2FA). 2FA in itself is a stronger mode of authentication, since, in addition to your password, you need to have something else - a ‘second factor’ - to prove your identity. The second factor, that you need to demonstrate possession of in a 2FA protocol, is commonly called a ‘token’. Not all 2FA protocols are equally strong though. The strength of a particular 2FA protocol depends in large part on the ease with which the token can be obtained, copied, reproduced, as this has direct impact on the comparative easy with which a token can be stolen.

Requesting two-factor authentication on LISA or Cartesius

LISA and Cartesius are the first SURFsara facility at which we support a 2FA procedure for end-users. For now, the usage of 2FA for end-users is still optional. To be more precise: as the principal investigator of a project is considered the owner of the projects and its data, only principal investigators can request 2FA. To do so, they must contact the SURFsara helpdesk.

Note:

If a principal investigator requests 2FA for his or her project, 2FA becomes mandatory for ALL logins that are associated with the project and have access to the project’s data.

In particular, individual users cannot send in tickets to be exempted from, or to undo, 2FA for their login. Neither will a request from principal investigators be honoured that requests 2FA for some but not for other logins associated with a project.

It is likely that 2FA on SURFsara facilities will become mandatory for end-users in the near future.

Enforcing logins to use 2FA to access LISA or Cartesius is a configuration operation that is separate and logically distinct from the operation of associating a login with a particular 2FA token. The latter is basically a self-service operation that is explained and documented below. To make the transition to 2FA as smooth as possible, it is best that users first obtain a token and familiarize themselves with the client application to use the token. When 2FA is enforced on a set of logins while some of the users have no valid token yet, or do not understand how to use it, those users are effectively locked out until they are able to use their token.

Time-based One-Time Passwords: a particular 2FA protocol

The first 2FA procedure currently supported on LISA and Cartesius is based on software tokens that use the Time-based One-Time Password algorithm (TOTP) to generate a 6-digit code. TOTP is a well understood and well-documented protocol (see: RFC6238, and also Wikipedia). It uses the current time as an input to generate a value that is unique and that is valid only for a very limited span of time after being generated (about 30 seconds). At each login you demonstrate proof of possession of the particular token that has been associated with your login name by responding with the 6-digit code that token the has generated for the current time interval.

Client applications

A TOTP token is a so-called software token. To possess a TOTP software token you need a TOTP compliant client application that can be installed and run on the operating system platform(s) of your preference, in which you can safely store a token identity that was created for you by a TOTP server.

The following list provides a number of locations where TOTP client applications can be downloaded. More client applications exist, there are quite a few to choose from. In principle any TOTP client should work well, but the list below only contains the clients that have been tested by SURFsara (October 2019), and verified to work well. There is at least one SURFsara tested client for each of the following platforms: IOS, Android, MacOS, Linux, and Windows.

TOTP clients for IOS

• https://apps.apple.com/gb/app/privacyidea-authenticator/id1445401301
• https://apps.apple.com/us/app/otp-auth/id659877384

TOTP client for Android

• https://play.google.com/store/apps/details?id=it.netknights.piauthenticator

TOTP client for MacOS

• https://cooperrs.de/otpauth_macos.html

TOTP client for Linux

• https://flathub.org/apps/details/com.github.bilelmoussaoui.Authenticator

TOTP clients for Windows

• https://winauth.github.io/winauth/
• https://www.microsoft.com/nl-nl/p/authenticator/9nblggh08h54

Tip:

Make sure you have at least one TOTP client installed and ready to be used on your phone or computer. Once a token identity is generated and presented to you (see below), it is associated with the loginname with which you entered the 2FA portal. You are expected to safely store and subsequently use it. You will no longer be able to login to the 2FA portal on the basis of username + password only.

Token creation at the 2FA portal

To create a usable software token you must obtain a token identity associated with your login from our 2FA portal, and safely store the identifier in the TOTP compliant app of your choice. This section explains in a few illustrated steps how to do just that.

• Step 1:
  To obtain the identity for your token, go to the specialised 2FA portal located at https://2fa.surfsara.nl. Since you have no usable token yet, you must login with the loginname you want activate 2FA for, and its corresponding password.
  (At a later stage the specialized 2FA portal will be moved to,and integrated in, the general end-user portal located at https://portal.surfsara.nl).

• Step 2:
  Once logged in to the portal, you are presented with a dialogue, as shown in figure 1, below, that has only one option, viz. to ‘enroll’ a new token. In this dialogue, click the green button to proceed.
  Figure 1

• Step3:
  When you see a dialogue, similar to the one shown in Figure 2, a token identity has been generated for you. It is presented to you, visualised as a QR code, You must store the token identity in one or more of your TOTP client apps.
  N.B.: DO NOT PRESS THE LOGOUT BUTTON BEFORE SAFELY STORING YOUR TOKEN IDENTITY WITH AT LEAST ONE OF YOUR TOTP APPS! Once a token has been generated for you, you are required to use it for authentication, and you will no longer be able to get into the portal on the basis of just your username + password only. Once a token identity has been associated with your login and you cannot use it you will need the help of SURFsara to delete the association of your login with that token identity.
  Figure 2

• Setp 4.
  Store the token identity in your app. It depends on your app how to do that:
  • A Phone-based app will let you scan the QR code;
  • A number of apps will also settle for text of the URL of the QR code image;
  • You can also click ‘The OTP key’. This presents a dropdown box similar to the one shown in Figure 3, which display a "Base32 encoded key" that you can store in text-based token apps.
    Figure 3

An example of entering a token indenty in a text-based app

WinAuth is an example of a TOTP client app for windows computers. Instead of scanning the QR code image, you must use the Base32 code, shown in Figure 3, and enter it as the ‘Secret Code for your authenticator’ in the WinAuth dialogue shown in Figure 4. Make sure that the app knowns the codes are generated time-based rather than counter-based.

Figure 4: Winauth

Guard your token identity well!

Not that your token identity, in all its possible representations – QR code image, QR code image URL, Base32 string – is a shared secret between you and the TOTP server. So be ware not expose such representations of your active, valid tokens. A malevolent person who steals your shared secret can generate new, valid TOTP values at will. Precisely because of 2FA this need not be fatal: in order to pose as you take on your identity, your password is needed in conjunction with the valid TOTP value. However, when your token is compromised, you should create a new one at the portal and delete the old one - see: ‘2FA.surfsara.nl revisited: managing your token(s)’.
If you have completely lost possession of your token, you will not be able to do so and must contact SURFsara for assistance.

The 2FA portal revisited: managing your token(s)

When you login to the portal with a login that has on or more associated tokens will find an overview of your token(s) under the ‘Tokens’ tab, similar to the overview shown in Figure 5.

Figure 5: Token overview

By clicking on the underlined token name in the left column, you can access a more detailed view shown in Figure 6. In the top right corner of the token details overview, you see a red button that can be used to delete the token. You must delete a token that is in whatever way was compromised and enroll a new token and store its identifier in you app(s).
Note that there is also an audit tab, which gives you access to the log token activity.

Figure 6: Token details