Helping users choose stronger passwords with known data breaches

Lars Smeby
ice Norge
Published in
4 min readApr 3, 2020
Photo by Shane Avery on Unsplash

ice is a new and upcoming cellular provider that’s set forth to challenge the telecom-duopoly in the Norwegian market through higher efficiency and better quality-of-service by utilizing no-legacy technology, digital customer journeys and with an extreme focus on customers, that’s articulated in a goal of “becoming Norway’s most recommended company”.

Telecom companies are attractive targets for attackers. We have a lot of data about our customers, some of it very sensitive. We’re also targets for SIM swap scams, an attack where a victim’s phone number is transferred to the attacker’s SIM card. It’s needless to say that it’s critical that we protect our customers.

The easiest solution

When you create a self-service account at ice, either through the ice app or on the web, you’re asked to create a password. Choosing a strong password can be hard, and users tend to go for the easiest solution that passes the password requirements, usually the same password as they use other places. It’s of course recommended to use a password manager, but let’s face it, most users don’t. By making the password requirements stricter, “password” becomes “Password”, then “Passw0rd”, and eventually “P@ssw0rd!”. Even though the entropy of the last example is much higher than the first, it’s still easy to guess for both humans and computers. And as of today, it has been seen 681 times in known data breaches!

A Dashlane analysis from 2015 found that the average user has 90 online accounts. Five years later, it’s probably more. As users tend to reuse their passwords on multiple sites, a data breach on one site will give valid credentials to other sites. Attackers use these lists of valid username and password combinations for what’s called credential stuffing attacks. They run all the combinations against a site’s login and see if they manage to log in with some of them. They usually do.

Have I Been Pwned

Troy Hunt runs a service called Have I Been Pwned that lets you search for your e-mail address in known data breaches. As of today, the service contains close to 10 billion compromised accounts. Most people have probably gotten their account compromised without even knowing it. Have I Been Pwned also lets you search for a password to see if it has been used in any of the compromised accounts. This service, which contains more than 555 million unique real-world passwords, is what we’ve started using to help users choose better passwords for self-service accounts at ice.

Password search at haveibeenpwned.com

Looking up the user’s password

When a user registers a new account or changes his or her password, we use the API from Have I Been Pwned to look up the password. If the password has been breached, we show a warning, urging the user to choose a different password. We also encourage the user to change the password on other sites if it has been reused. The warning reads:

“The password you have chosen has previously been leaked in a data breach on a different website and is considered unsafe. We recommend that you choose a different password.”

There’s also a link, “How do we know?”, that shows more info about data breaches and how we use the API at Have I Been Pwned. To proceed with a breached password, the user must confirm that he or she understands the risk by checking a checkbox.

Registering a new user in the ice app

So, you send my password to an external site?

No! The API at Have I Been Pwned implements a k-anonymity model that lets us search for a password without the password itself leaving our servers. This works by hashing the password with SHA-1, and then sending the first five characters of the hash to the API. Since changing a single character in the password would create a totally different hash, the first five characters won’t give away any clues about what the entered password might be, if intercepted. The API responds with all password hashes starting with these characters, usually a couple of hundred. If we find the full hash of the password amongst the returned hashes, we show the warning to the user.

Educating the users

As mentioned earlier, enforcing a strict password policy doesn’t necessary lead to stronger passwords, as users tend to choose predictable passwords that barely meet the requirements. What it definitively leads to, however, is annoyed users. By instead educating the users, trying to explain in a friendly way why their chosen password is insecure, we let the users themselves make the decision of creating a strong password. And does it work? By collecting anonymous statistics on the number of warnings displayed and what the users choose to do, we see that 80% of the users that get the warning change their password to something else. That’s a significant share of users!

--

--