When it comes to password security on social networking sites, such as LinkedIn or XING, users usually have to rely on the website's claims. Because these sites are closed source applications, users don't know for sure how their passwords are protected. Often, by the time they find out, it may be too late. In 2012, for example, LinkedIn lost an estimated 6.5 million encrypted passwords. There may have been more as the company did not provide exact figures, because in 2016 a hacker offered to sell 117 million LinkedIn users' customer data [1].

Of all the types of stored data, user passwords are a particularly attractive target. One reason for this is that many users reuse a password for more than one site. Once an attacker has cracked a user's password on one site, they can use it to exploit other sites as well. Another reason is that the passwords many people choose are just too simple.

While all social networks store personal data, open source solutions, such as my project vutuv [2], are usually more open with their security approaches (see the box "Open Source Infrastructure"). Read on for a behind the scenes look at how our site goes about securely storing passwords.

Password-Free Is PassÈ

In vutuv's first version, we completely dispensed with user passwords and used a Magic Link instead. When logging in, a user only had to enter their email address; they were then sent a newly created Magic Link that would enable logging in without a password.

Quite proud of our secure Magic Link solution, we awaited community praise after the platform launch. Instead, we started getting support requests: Where do I enter a password? How do I set the password? The answer that vutuv did not need a password was something that none of the users found worthy of compliment.

We learned from this experience. For end users, it's completely normal to log on to a website with some kind of account name and password and to reset forgotten passwords by email if necessary. For 99 percent of our users, logging on with a Magic Link turned out to be non-intuitive and did not meet our target audience's needs. At the beginning of 2019, we decided to develop a second version, which among other things required a legacy login password [2].

Second Try

Instead of reinventing the wheel for password functionality, we implemented the Phoenix authentication library, Phauxth [9]. Since we had special system requirements, we quickly entered into an exchange with the library inventor, David Whitlock, who now is working full time for the vutuv core team on version 2.0.

For any web application, the worst case scenario is a hijacked server. An attacker would then have full access to the database and all the configuration files on the server. In vutuv's case, the attacker would probably have grabbed the source code from our public GitHub repository [2] in advance and studied it. For that reason, we do not use an encrypted database. Not only does it impact speed, but if an attacker has complete access to your system, encryption is pointless. The Phauxth authentication library ensures that an attacker who gets on your server system will not be able to extract passwords.

Brutally Simple

The simplest attack is a dictionary attack in which attackers try out popular passwords using brute force. This type of attack doesn't even require breaking into the target system. However, the attacker does need an account name that uses a weak password.

To prevent brute force attacks of this kind, vutuv uses a login limit. After three unsuccessful attempts, a user has to wait a few minutes until the next attempt. After further unsuccessful attempts, the wait increases and the system triggers an internal alarm.