1. NSC
  2. User support
  3. Two-factor authentication
  4. Why 2FA?

Background

In order to login to an NSC cluster that is not using two-factor authentication you need a username and a password (or a username and an SSH private key1).

Both passwords and SSH keys are possible to steal2. Stolen passwords or SSH keys can then be used by unauthorized persons to login to the cluster.

Why this matters

Any intrusion that gives access to a user account puts that project’s data at risk. It can be read and copied, modified or deleted.

But the problem is not limited to just that one project. Once logged in, an attacker will typically also use the account to try and elevate his privileges3 and gain full administrative access to the cluster. If successful, all project data is at risk, and it is also possible to plant back doors or malware that continues to steal new data or user credentials.

If such an intrusion is not detected, the attacker can continue doing damage for a long time. The first time it’s noticed might be when your research data is published by someone else.

If such an intrusion is detected, NSC will have to take the cluster offline for lengthy (probably weeks rather than days) investigations and cleanup work4. This means you will temporarily lose access to the cluster and your data, and NSC will have to spend lots of time on cleanup, time we would much rather spend on helping you do research on our systems.

So all intrusions are bad, and we would really like to avoid them if possible.

Why TOTP

This method is used by Google, Twitter, Microsoft and many others. It's also already in use within SNIC (e.g SUPR, LUNARC, UPPMAX).

Our reasons for choosing TOTP:

  • It requires no distribution of physical tokens (e.g Yubikeys) to users
  • It is quick and easy to implement on our clusters
  • It is already familiar to many users
  • It requires no extra software installation on user’s computers

  1. ... where the public part of the key has been added to the file .ssh/authorized_keys in your home directory on the cluster.↩

  2. It’s more common for malware to steal passwords, but SSH keys are also being stolen, so we want to address both issues. Passwords and keys can be stolen through a compromised system that you login to and then login to Tetralith from there or through malware on your own computer that eavesdrops on keystrokes and steals files.↩

  3. NSC tries very hard to be proactive and update our systems as soon as security vulnerabilities are made public. But there will always be some time lag, and not all vulnerabilities are made public. In general, it is much easier to get full administrative (“root”) access to a system using a vulnerability if you can login to the system rather than having to attack from the outside.↩

  4. Forensic investigations, checking, reinstalling or restoring data and software from backup, ...↩


User Area

User support

Guides, documentation and FAQ.

Getting access

Applying for projects and login accounts.

System status

Everything OK!

No reported problems

Self-service

SUPR
NSC Express