Hacking for Good

In July this year the edu-ID account management was reimplemented almost from scratch. Not only did the design change but so did much of the technology behind it, including the programming framework. Because we take security and data privacy very seriously, we asked our colleagues from the Switch security team to do a preliminary penetration test before the launch. This first penetration test provided us with the confidence to release the new account management into the wild. But to be doubly sure, we decided to run also a second penetration test after launch with an external company. And so we did.

As in previous years we hired the experts at Compass Security, with whom we have had very good experience in the previous penetration tests for edu-ID. They used one week in October to find vulnerabilities in the new production account management. So far we have had different testers each time. Although they use the same impressive set of tools and have similar skills, it has always proved beneficial to have different testers with slightly different perspectives. This comes into play in the manual hacking phase when they actively try to exploit vulnerabilities using different techniques.

Yes, of course they did! Unless your application is a simple hello world program, it’s very likely that vulnerabilities will be found. The question is rather how serious they are.
We were pleased to hear that Compass Security did not find any vulnerabilities that they would consider critical. However, they did identify two high-severity vulnerabilities (header injection, blind cross-site). One was already fixed already during the testing phase, the other shortly after.

Of the remaining 9 medium and 20 low-rated vulnerabilities, many have already been fixed or will be fixed in the near future. As in previous penetration tests, there are a few low-rated vulnerabilities that are so difficult to exploit that the effort or side effects of fixing them outweigh the cost of fixing them. An example of a vulnerability we won’t address is the blocking of some slightly less secure key algorithms for Passkeys. Blocking them would exclude all users of Windows 10 devices. This would not make edu-ID much more secure, but would prevent many users from adopting passkeys. Even using slightly less secure Passkeys is much more secure than continuing to use username/password for login.

Other examples include cases where edu-ID reveals some information, for example to prevent duplicate accounts. While almost any disclosure of information is bad from a security point of view, it can be beneficial for usability and potentially save many support tickets. So, for medium and low rated vulnerabilities, the team often has to discuss the effort and negative side effects of addressing them.

While there still remain some vulnerabilities to address, we are very glad with the outcome of the penetration test. It shows that the required security awareness and expertise are present in the team that develops and operates edu-ID.