Words: Alvise Rabitti, Ca’ Foscari University, Venice, Italy
Since the beginning of 2023 every staff member at Ca’ Foscari University in Venice has been using multi-factor authentication to gain access to the majority of the IT services provided by the University. This is the story on how we convinced 4,000 people to overcome a small hurdle in order to boost their accounts’ security.
MFA?
Multi-Factor Authentication (MFA) is currently the most widespread strong authentication mechanism adopted worldwide. To prove their identity, users must provide at least two of these three types of credentials: something the user is (e.g. a fingerprint), something the user has (e.g. a USB token), something the user knows (e.g. a password). The sheer password-based authentication is often not enough to effectively protect user accounts. The ever-growing computational power and various clever tricks make password cracking a threat even for complex passwords, and the daily hammering of well-built phishing campaigns make the risk of leaking the plain-text password very real. Of course, MFA is not a silver bullet, but can make things significantly harder for an attacker, often leading them to look for easier targets. On the flipside: MFA could make things significantly harder for users too, up to the point where they try to avoid it (degrading security) or even completely remove it.
Ca’ Foscari
The Ca’ Foscari University of Venice welcomes more than 20,000 students e about 4,000 staff members, including teachers, researchers, technicians and admins. By means of a Single Sign On (SSO) system these users have access to a wide range of IT services: from WiFi access via eduroam, to email accounts; from online career management to VPNs and Windows systems accounts. Expecting the switch to MFA to have quite an impact, we chose to begin with a quick proof-of-concept for a selected number of users. This proved successful, so we quickly moved to get the whole personnel onboard, as these individuals access the most delicate resources of the University. While limited in numbers, staff members include roles, with a varied educational background and technological proficiency: the MFA system we were looking for had to work for the younger IT security professor, but also for individuals who are more resistant to new technology. Not to mention the transversal party of “it always worked this way, why should we change?”.
Authentication Factors
Thus, our first concern has been to go for a “lightweight” second factor of authentication.
We chose between:
- SMS codes (too weak);
- Fingerprints (require dedicated hardware and software);
- USB tokens (hard to manage the distribution and the, unavoidable, loss);
- HMAC-based One Time Password;
- Time-based One Time Password.
Looking at the last two: Time-based One Time Password (TOTP) seemed the most flexible. Its various implementations allowed us to meet users’ needs without losing too much security.
TOTP
Time-based One Time Password is an algorithm that computes a One Time Password (OTP), changing every 30 seconds, by using:
- a secret shared between each user and the server;
- the time at the moment of the computation.
As the computation is not trivial, the user needs an electronic device to get the correct OTP. The knowledge of the correct OTP may then be accepted as a proof of possession (something the user has, as we called it before) of a device that the user has previously authorised with their shared secret.
Deployment
Setting up the technical part of the deployment has been quite easy: Shibboleth, the system we use for SSO, has a working TOTP plugin, and the integration with other relevant University systems and procedures has been designed and implemented by sysops and developers without any real issue. As far as applications for computing the OTP are concerned: there are many, free, open-source options available for all major devices, we chose to let users free to decide which one to use. Technology is not the real issue, here, although the human factor…
Speaking of the latter: at first we managed all the IT-support staff working within the faculties. We had dedicated meetings with them, we listened to their worries, we answered their questions. These meetings and the support from these colleagues proved essential in the very first stages of MFA activation, and provided important contributions to the users’ documentation. The documentation has been integrated in a specifically designed communication strategy: with proper warnings, guidelines, FAQs and user-friendly interfaces we managed to have most users self-activate the OTP system without real issues. Notwithstanding the plan I just described, one of our main worries was the eventuality that 4,000 people might raise issues all at once. We took advantage of the recurring password change that every user has to perform in order to require the OTP activation. The user had to initialise a device with a shared secret, and from then on MFA was required. In the second half of 2022, we were able to dilute potential problems for about six months and were able to fix issues on the go. For instance, FAQs changed many times to better fit users’ real questions.
Challenges
One of the most reported problems was from people who wouldn’t, or couldn’t install an application to deploy the OTP on their smartphone. That was the suggested option, but not everyone has a smartphone. Being able to leverage desktop applications or even browser extensions allowed us to switch the proof from “I have an authorised smartphone” to “I have an authorised PC” and totally settled these kinds of objections. Another concern was caused by the non-personal email accounts (e.g. the “office” ones). Users who accessed these accounts by sharing the password suddenly saw their (questionable) system undermined. MFA eventually forced them to use the account delegation system, scoring an additional improvement. In those cases where delegation was not an option we allowed them to share the secret between different users. We had to compromise, but it was an improvement to the previous situation. All other issues were various flavours of “I lost the shared secret”: sure they were a burden for the user support team, but we foresaw them and set up tools and procedures to addres this. On a happy note: ideological enemies were just a handful and their opposition had no real impact, since we shared the aims and motivations with senior management and the very same Director General was part of the first group of early adopters.
Results
In about six months all personnel of the University switched to MFA for most IT services (we still have some left out for technical reasons which we should soon overcome), and the calls for user support are fewer and fewer. Along with account security, the overall awareness seems to have improved: people security reports became more meaningful and there seems to be more acceptance of other related best practices. We haven’t been aware of any unauthorised access to a MFA enabled service since then, yet we can acknowledge that the system is indeed working: sometimes, sifting through the logs, we notice some weird login attempts (e.g. same timeframe as another login, but from a geographically distant IP address) that get the password right, but stop at the OTP request.
Takeaways
- MFA can be implemented easily and completely with opensource software: the real issue is not technology.
- Great help comes from a communication plan and a carefully written documentation.
- A well-managed and patient user support team is essential.
- It’s absolutely worth it!
About Alvise Rabitti
Alvise is the IT security manager of Ca’ Foscari University – Venice. As a child, he was amazed that a Commodore 64 obeyed his commands, so he began to try and understand how to make computers work, quickly moving on to try and make them work differently than expected. Understanding how to trick systems still seems to him to be one of the best ways to protect them. As an information security researcher, he has contributed to dozens of responsible disclosures with national and international recipients, and published works at various conferences such as USENIX, IEEE Security & Privacy, and in peer-reviewed journals.
Also this year GÉANT joins the European Cyber Security Month, with the campaign ‘Become A Cyber Hero‘. Read articles from cyber security experts within our community and download resources from our awareness package on connect.geant.org/csm23
