Monash University enrolled 130,000 users in multi-factor authentication last year after being targeted by the Silent Librarian phishing attack that hit hundreds of universities worldwide.
The phishing attack, blamed on Iranian hackers, netted over 30TB from “144 US-based universities [and] 176 universities across 21 foreign countries”, US prosecutors said last year.
PhishLabs, which spent two years tracking the threat actors, said at the time that Monash University had been a repeated target.
“Monash University, located in Australia, has been a popular Silent Librarian target,” it said.
“The university has been targeted more than two dozen times by the group since the beginning of 2017.”
The attackers used a ruse that a researcher’s library account was expiring in order to phish their log-in credentials - leading to the ‘Silent Librarian’ name.
Solutions architect Andrew Collins and systems engineer Cameron Duck told Okta’s recent Oktane19 conference that the attacks - and cyber security threats generally - drove the university’s executives to back an authentication uplift.
“Our CIO saw some of the attacks that we'd been under like the Silent Librarian attack, and he was able to push the requirement [for better systems] back up the tree,” Duck said.
Monash had been using Active Directory Federation Services (ADFS) for single sign-on (SSO) to applications and IT services like email. The call was made to move off ADFS in favour of Okta.
Collins said that the transition was broken up into “three manageable phases.”
Work started in May last year and the university cut over to Okta on June 28.
“Our first phase was to federate Okta with ADFS,” Collins said. “Our second phase was then to migrate all of our applications from ADFS over to Okta.
“Our last phase was to roll out MFA to our organisation, and this was going to be one of our biggest challenges.”
The first phase of work ultimately resulted in the university presenting users with an Okta login page instead of an ADFS login page.
The aim was for user authentication instructions (communicated in packages called “assertions”) to be handled by Okta.
“We needed to make sure that Okta would pass through all the attributes that ADFS would need to create any assertion for any application, and we needed to make sure that ADFS would now take those new attributes rather than the ones coming directly from AD [Active Directory],” Duck said.
Once this worked, the university started to move the authentication mechanism of applications from ADFS to Okta.
Collins noted this was particularly time-consuming, finding contact details for application owners and then getting them to commit to migrate the authentication portion of their applications.
“We created a migration schedule, which consisted of 20 windows over a 34-day period so then application owners selected one of these windows on when they were going to migrate,” he said.
“We capped this at about 10 applications in these windows so then we could concentrate just on migrating those ones in that window.”
Collins said that Monash was “able to pre-stage all of our applications in Okta prior to the migration windows.”
“This allowed us then to send the metadata and configuration files to the user, so then they could work out what they needed to change,” he said.
App owners were also given a QA environment to run end-to-end tests to “make them feel very comfortable” by the time migration day came around.
Still, scheduling the change proved difficult, especially as not all apps in the university were well-documented.
“We had quite a few applications that were very old, very handwritten and very awful, and that no one knew how they were configured,” Duck said.
“We had people having to go in and work out how the authentication within the app worked, and we'd have to go in and help the [owners] work out how to change these applications over.”
Deploying MFA
At this point, the university was finally able to tackle multi-factor authentication (MFA).
“Early on in the piece, we found that there was really no graceful way of introducing MFA out to our organisation, so we came up with this idea to create an opt-in page,” Collins said.
“This was a page where a user could go to and opt in for MFA at a time convenient to them.
“Just imagine rolling out MFA to thousands or 10,000 people at a time. They might have had a presentation to do or a student might have had to submit an assignment.”
The opt-in page was live for a fortnight before MFA usage was enforced.
“We rolled this out in stages through our faculties and in batches of students,” Collins said.
“While we were rolling this out, we made sure all our support mechanisms were in place as well, so we had people walking around helping people sign up for MFA.
“When someone was calling the service desk they also helped them sign up for MFA.”
Several options are provided for the second-factor.
“The factors that we went with were Okta Verify with Push, Google Authenticator, Yubico OTP, and Universal Second Factor (U2F),” Duck said.
By default, all users are given Okta Verify and Google Authenticator factors.
“We adopted Verify because it's very easy to sign up - just scan the QR code and off you go,” Duck said.
“Google Authenticator was turned on because we have some user base that doesn't change over their phones very often and can have very old operating systems - some so old that Okta Verify wouldn't actually run on them. We also used it as a backup code because currently Okta Verify doesn't restore when you change phones over, whereas some authenticator apps do.
“The U2F factor is another very easy to use factor - you plug your key into the side of your laptop, you press the button and you're in.
“But once again, we ran into a couple of problems. Our VPN doesn't support U2F and neither do some browsers, so for users that didn't have a phone, we provided them with a Yubikey and used the one-time password (OTP) factor.”
Duck specifically noted the absence of security questions and SMS/voice as an authentication factor.
“It's because security questions are very easy to get around, to socially engineer [access to] the answers, and for SMS/voice it's also easy for the person trying to get into your account to call your phone company and convince them to port your number to their SIM, in which case they will get the SMS message to give them the code to log into your account,” he said.
Edge cases
The number of factors is in part a recognition that not every authentication situation at the university is straightforward.
Duck said that several “special scenarios” arose and had to be considered.
Some accounts - such as for a reception - were shared by multiple users. “For these accounts we used Google Authenticator, because you can enroll multiple devices against the one account,” he said.
Another complication arose for senior staff with executive assistants (EAs).
“Unfortunately, some of our applications don't allow for delegated tasks, so for the EAs to do their job, they needed to log in as their boss,” Duck said.
“In those cases, the senior staff member would enroll Okta Verify on their phone, and then we'd set up a Yubikey and give that to the assistant, so that when they needed to log in as their boss, they could do that.”
As a research institution, the university ran lab environments did not permit phones or even Yubikeys being brought in, for fear of contamination.
“In those cases, we set up a network zone that said, ‘any machines that are in these labs don't need to MFA’. It doesn't matter who logs into them.
“We consider the lock on the door for the lab [as] the second factor,” Duck said.
Another special use case was electronic exams. Duck said that another network zone was set up so that students logging into exam-provided laptops did not need to use MFA.
This use case could become more complicated in the future as the university explores allowing BYOD devices to be used to complete exams.
“We are looking later on this year to be able to do a BYOD for the exams, and I'm sure that's going to be another conversation with our network team to work out exactly what we're going to need to do for those ones,” Duck said.
SSO policy-setting
When a user signs into MFA on their own laptop, they are able to select a 'Don't prompt me on this device again' option.
“They also have a long session life, so worst-case scenario, they have to login twice a day if they work 24 hours a day,” Duck said.
He noted that researchers, staff and students often travelled in their line of work.
“So we set a policy that says the first login from a new country, once again, you must MFA,” he said.
“So when I landed here in San Francisco [for this conference], even though it was my laptop and I'd ticked the box before, I still had to MFA because it was a new country, and I'll have to MFA again when I get back home to Australia.”
If the user is logging into the corporate VPN, they must authenticate using MFA each time.
“Because the VPN is a good access point into our network, we made sure that you must MFA every time you VPN in, because we want to make sure that the people on our network are meant to be on our network,” Duck said.
Restrictive controls are also in place for privileged accounts.
“For example, all of our Okta admins are only allowed to use a U2F token as their second factor - no Okta Verify or anything like that - and they have a very short session length time,” Duck said.
“We wanted to make sure that our accounts that have the most access also have the highest security on them.”
Yubikey distribution
The Yubikeys for MFA are ostensibly for users that do not have a phone, but one of the main use cases is in instances where users do have a phone but don’t want to run the Okta Verify app on it.
“One of the most frustrating things was people who didn't want to use their personal device for MFA,” Collins said.
“Our solution to this was to supply them a Yubikey.
“This worked in most cases, except for when they wanted to access say email on their phone, and it didn't support USB.”
Duck said the university has “about 2000 keys in the wild out of 130,000 enrolled users” in MFA.
Lost or upgraded phones
The university is also working on a backup feature that will allow users to change their handset without impacting their ability to use it for MFA.
“The number of people who either lost their phones or damaged or upgraded their phones, we were getting around about 1000 of these per week,” Collins said.
“Because we didn't select SMS [as a factor], it wasn't as simple as taking SMS out of one phone and putting in the other one, and then they continue to do MFA - so they had to call the Service Desk.
“So at the moment, we're working on a backup feature. It's a website that users can go to, register for 10 one-time backup codes, and store that safely in a personal vault or wherever, and when they need to reset their phone, they can go back to the website and enter in their one-time code and reset their own factor.”
Duck noted that once the one-time codes were generated, users could store them in a vault, email themselves the codes (to a non-Monash address), print out the codes, or save them in a text file.
