A recent experiment by Gizmodo’s Kashmir Hill and Alan Mislove of Northeastern University raised concerns that Facebook may be “letting advertisers reach users with contact information collected in surprising ways.” One of those “surprising” ways that immediately raised concern among security experts is the ability to leverage phone numbers collected for use in Multi-Factor Authentication (MFA) for advertiser targeting.
In other words, this article asserts that if you’ve submitted your mobile phone number to Facebook as a secondary authentication factor, advertisers on Facebook can use that information to target you for ads.
Why this is an issue
To some extent, data collection is a natural part of comprehensive and effective cyber-security. Regulators as well as the public (you and I), tend to accept the collection of private data - such as mobile phone numbers - when it’s for the purpose of fighting the bad guys and keeping our information secure.
Phone numbers, as well as other security-related data, are classified as Personally Identifiable Information (PII). This means that they can be used to identify, contact, or locate an individual. As such, this security-related data has significant potential monetizable value.
The value of this information, coupled with the fact that users are more likely to share personal information for security purposes, creates a natural temptation for vendors to leverage this security-based data for commercial purposes.
Vendors that collect personal data are therefore asked to provide a clear purpose for the way this data will be used, and are expected to follow that particular purpose. Specifically, when we agree to share PII for security purposes, it is done with the base assumption that this information will be used only for the purpose of providing safer and better cyber-security - Not for business purposes outside of that scope like advertising.
This is critical for the adoption of security technologies by the industry. And just as importantly, it’s crucial for the trust and adoption of security options by consumers. It’s all about maintaining trust between all parties that are in this journey to provide safer and more secure digital age.
What developers can do
If you are a developer, here are three recommendations on how you can responsibly handle user PII going forward.
Familiarize yourself with and leverage security best practices: We recommend that all app developers support MFA using native mobile Authenticator apps, while also reducing their use of SMS-based MFA and security questions. If you must use one of these methods, understand the associated risk and PII considerations. It may seem dry, but the NIST 800-63B Guidelines provides some very valuable information. Give it a read.
Separate security data from business data: Using separate technology and teams for the management of security data and business data is critical for maintaining trust with your users. Consider using external Customer Identity and Access Management (CIAM) services. Full disclosure: OneLogin is a provider of such a CIAM service.
Make your security practices public: Let users know exactly how their data will be used in your customer service agreement and customer consent form. Explicitly state what types of information will be collected for security purposes, and explain the boundaries of that data’s use. Be clear on what data is subject to use for commercial purposes, and to what extent.
What users can do
Luckily we, the individuals who own this data, can also easily address this particular alleged misuse of information.
A simple and proven approach is to leverage Mobile Authenticator apps, such as Google Authenticator or our own OneLogin Protect instead. These native mobile applications tie your identity to a device rather than to PII, such as a name, phone number or email address. These apps provide superior security, will not collect PII, and are free for all to use.
In the information age, the responsible and transparent use of PII is critical for maintaining trust between service vendors and their users. Hopefully this post has shed some light on how that trust can be violated, what developers can do to protect that trust, and how users can better protect themselves going forward.