New authentication @

Today we have launched a new authentication system within It marks an important milestone in our journey to modernise key processes of our infrastructure. is close to celebrating its 20th anniversary. Any software engineer will hear that number and understand what comes with it: tech debt. It's as unavoidable as it is hazardous, and I believe over the years we have learned to expect it, tackle it, and move forward without being held back by the past.

For the best part of the last decade authentication on the different funda websites was done via an ASP.NET Membership provider, which would one-way hash passwords with MD5, salt them and store them in a database. MD5 being a hashing algorithm that is optimized for speed, means that as the years went by and computing power became cheaper and more efficient, it became fairly easy to spit out billions of MD5 hashes per second, even salted ones, and compare them to a compromised hashed password to find out a user's original password.

Fortunately, over the years, we have never had a data breach within Funda that would allow access to said hashed passwords, but still, we felt it was imperative to modernise our authentication system to not only use more robust hashing mechanisms, but also general best practices regarding how both internal and external systems handle authentication and authorization.
So, for the past few months, we have been creating a separate identity provider based on Identity Server 4, a certified OpenID Connect and OAuth 2.0 framework for ASP.NET Core, adjusting all websites and services that have custom authentication or authorization implementations, to delegate those tasks to the identity provider, following a federated identity model.

Within Identity Server 4, we chose to tackle user account management via ASP.NET Core Identity and, specifically for hashing, we use its own PasswordHasher, which uses PBKDF2 by default, a much slower, and thus safer, hashing mechanism.

With a new authentication system in place, we also had to think about migrating existing user accounts successfully. Since we only store hashed passwords and have no way of deciphering the original passwords (which is of course a very good thing!), moving these accounts to a new system was a challenge. We decided thus to start saving existing credentials in the new system when users would log-in on the old system, so we would be able to have a seamless transition to active users when we would disable the old system and depend solely on the new one.
This comes with the downside of having to ask other less active users to reset their password when they want to login, as soon as we stop the old system. Effectively, we are saving their hashed password for the first time in our new system.

Unfortunately, that does mean some users will be alarmed when receiving an e-mail from funda asking them to reset their passwords, as so often that is a sign that some system was compromised.
In this instance, it is actually the polar opposite: even though there have been no data leaks within, we are moving to a more robust authentication system to make sure that if our systems are ever compromised, attackers won't be able to decipher our users' passwords.

CTO @ funda