Two-Factor Authentication

The Office of Research Computing now requires enrollment in the department's two factor authentication solution.

Why is two-factor authentication useful?

Two-factor authentication is a security best practice. It may be easy to steal usernames and passwords on a user's computer as they are typed, but it is extremely difficult to also target that same user's second factor device. This greatly enhances security because simple attacks to gather usernames and passwords are now almost worthless.

Why is it required?

In addition to being a really good idea, two-factor authentication is mandated as part of some government contracts. The Office of Research Computing processes various kinds of protected data such as those required to abide by NIST SP 800-171, a federal information security standard. There are other kinds of protected data that also require two-factor authentication, such as dbGaP.

Some users may wonder why they must enroll in two-factor authentication even if 100% of everything they do could be published in a public github repo. The answer is that we must protect the overall system, not just individual accounts. Each account must have a high level of security in order to increase the system security and, again, it is mandated as part of federal contracts that we protect the entire system so that the data is secure.

Why don't we use campus authentication in general and Duo in particular?

The answer is complicated and we know that this is an annoyance for some users. This separate system requires you to maintain an additional password and an additional two-factor token.

The Office of Research Computing staff have spent a lot of time over many years deciding on the best approach and, for now, the best approach is still to maintain our own authentication system. The best approach might change in the future but for now there are no plans to change.

A minor reason for not using Duo is that our two-factor implementation predates the adoption of Duo by the rest of campus. We have no reliance on external services except for account creation and password resets. We try our best to keep our systems operational 24x7x365 and find that reliance on additional external services that also undergo both planned and unplanned outages is sub-optimal.

Ultimately, the overriding factor is that the current implementation of CAS and Duo is insufficient to satisfy some of the strict federal requirements we must abide by.

ssh keys and automation

Unfortunately ssh keys are a single factor and must be disallowed when connecting to Office of Research Computing systems.

For those of you who use ssh keys for automation, we have a solution for you: the new RHEL 7 image allows for cron usage on login nodes. The cron daemons are clustered so that you can edit or modify your crontab from any login node but the entries only run on one node at a time. Rather than using cron from outside of Office of Research Computing systems, you can now run cron from inside the Office of Research Computing.

We understand that ssh keys can have a password set on them such that the key plus password would arguably be considered two factors. However, there is no way that the server-side ssh daemon can know if the client's ssh key is protected by a password or not. We must therefore assume that the ssh key is unprotected, especially since that is the default configuration on all client systems we know of.

We know that this is extremely inconvenient for some of you (us included). This particularly affects workflow automation; we would like to work with you on more secure workarounds if this is what you use ssh keys for. We think the clustered cron approach will work for most use cases. If not, please open a support ticket and we'll see what we can do to help.

It is inconvenient

We agree that two-factor authentication is inconvenient. We probably log into our systems on a daily basis more than anyone else. We really do understand the annoyance but it is just a fact of life in this day and age.  

Making life easier

To make life a little bit easier, we recommend checking out our page on SSH Multiplexing.