Limited password portfolios of users are a security threat to all applications. I am suggesting an approach to responsibly disclose breached accounts to users during signup. This can help users to get a better understanding of the situation and hopefully motivates them to use a new password or activate two-factor authentication.
E-Mail Address
Services require a customer to provide an E-Mail address and a password during signup. The E-Mail address is essential for login, password recovery and all communication between service provider and customer. Consumer research shows an average of 1.7 to 1.9 E-Mail accounts per user. This means that there is a high probability that a user will use the same address over years and for multiple service signups.
Password
The password should be distinctive per service but 31% of customers use only two to three different passwords. The question is also how different those passwords are. 83% of users admit to re-using passwords. Password managers are very helpful to provide unique passwords for each account but hardly anybody uses them if not forced by company policy.
Data Breaches
Companies get hacked or information is unintentionally exposed to the public. Data sets with millions of accounts have been seen in the wild. Clear text passwords or hashing without salt are not uncommon in user databases. Attackers use the information of those exposed data sets in attacks against other services. The known E-Mail address and password combinations are used for account takeovers. The method is called credential stuffing attack.
Security aware users counter this with the use of password managers and two-factor authentication, but the majority of users doesn’t. Service providers are afraid to enforce hard requirements in fear of customers not signing up or the usability of a service degrading.
Myself
I use the same E-Mail address since 2005. The address has been leaked in the following hacks:
verifications.io
In February 2019, the email address validation service verifications.io suffered a data breach. Discovered by Bob Diachenko and Vinny Troia, the breach was due to the data being stored in a MongoDB instance left publicly facing without a password and resulted in 763 million unique email addresses being exposed. Many records within the data also included additional personal attributes such as names, phone numbers, IP addresses, dates of birth and genders. No passwords were included in the data. The Verifications.io website went offline during the disclosure process, although an archived copy remains viewable.
Compromised data: Dates of birth, Email addresses, Employers, Genders, Geographic locations, IP addresses, Job titles, Names, Phone numbers, Physical addresses
Tumblr In early 2013, Tumblr suffered a data breach which resulted in the exposure of over 65 million accounts. The data was later put up for sale on a dark market website and included email addresses and passwords stored as salted SHA1 hashes.
Compromised data: Email addresses, Passwords
MySpace In approximately 2008, MySpace suffered a data breach that exposed almost 360 million accounts. In May 2016 the data was offered up for sale on the “Real Deal” dark market website and included email addresses, usernames and SHA1 hashes of the first 10 characters of the password converted to lowercase and stored without a salt. The exact breach date is unknown, but analysis of the data suggests it was 8 years before being made public.
Compromised data: Email addresses, Passwords, Usernames
LinkedIn In May 2016, LinkedIn had 164 million email addresses and passwords exposed. Originally hacked in 2012, the data remained out of sight until being offered for sale on a dark market site 4 years later. The passwords in the breach were stored as SHA1 hashes without salt, the vast majority of which were quickly cracked in the days following the release of the data.
Compromised data: Email addresses, Passwords
Dropbox In mid-2012, Dropbox suffered a data breach which exposed the stored credentials of tens of millions of their customers. In August 2016, they forced password resets for customers they believed may be at risk. A large volume of data totaling over 68 million records was subsequently traded online and included email addresses and salted hashes of passwords (half of them SHA1, half of them bcrypt).
Compromised data: Email addresses, Passwords
Disqus In October 2017, the blog commenting service Disqus announced they’d suffered a data breach. The breach dated back to July 2012 but wasn’t identified until years later when the data finally surfaced. The breach contained over 17.5 million unique email addresses and usernames. Users who created logins on Disqus had salted SHA1 hashes of passwords whilst users who logged in via social providers only had references to those accounts.
Compromised data: Email addresses, Passwords, Usernames
My E-Mail address was also in the Collection #1. This data set contains multiple data breaches and almost 2.7 billion records including 773 million unique email addresses alongside passwords.
I am not in possession of all breached databases but the service ’;–have i been pwned? does a great job of collecting this information. HIBP allows to check E-Mail address via their web interface and with a public API against those databases.
Disclosure to the User
At signup, the customer provides his E-Mail address. We can check this address with the API of HIBP (make sure the users agrees to the third party sharing of his data) for prior exposure.
While the potential positive results are shared with them we can make suggestions on how to improve the account security (eg. two-factor authentication). Service providers can also require tougher security features on the account. This could be a more complex password policy or a more secure policy regarding changes to the account.
Conclusion
We need to involve non-technical people to improve security. Disclosing information to users about past breaches is a great way to help them to harden their account and change behavior regarding password recycling. Service providers should not shy away from this and instead make users understand that security is taken seriously in the service they are signing up for. Building trust in a zero trust world.