A coalition of the four largest U.S. wireless providers calling itself the Mobile Authentication Taskforce recently announced an initiative named Project Verify. This project would let users log in to apps and websites with their phone instead of a password, or serve as an alternative to multi-factor authentication methods such as SMS or hardware tokens.

Any work to find a more secure and user-friendly solution than passwords is worthwhile. However, the devil is always in the details—and this project is the work of many devils we already know well. The companies behind this initiative are the same ones responsible for the infrastructure behind security failures like SIM-swapping attacks, neutrality failures like unadvertised throttling, and privacy failures like supercookies and NSA surveillance.

Research on moving user-friendly security and authentication forward must be open and vendor- and platform-neutral, not tied to any one product, platform, or industry group. It must allow users to take control of our identities, not leave them in the hands of the very same ISP companies that have repeatedly subverted our trust.

The Good

As the Taskforce lays out in their teaser video, the challenge of using passwords securely is a direct factor in a huge number of account breaches. EFF has long recommended password managers as a way to create and manage strong passwords.

Some providers have begun offering Single Sign-On, or SSO, which serves as an alternative to keeping track of multiple passwords. When you see options to “Sign in with Facebook” or “Sign in with Google” on other websites, that’s an example of SSO. A recent Facebook breach points to the pitfalls of an SSO system that is not well implemented or published and developed openly for community auditing, but on the whole this method can be a big win for usable security.

Project Verify appears to fall under this category. With Single Sign-on, you authenticate once to the SSO provider: a corporate server, a site using a standard like OpenID, or, in the case of Project Verify, your mobile phone provider. When you then log in to a separate site or app, it can request authentication from the SSO provider instead of asking you to register with a new username and password. You may then have to approve that login or registration with the SSO provider, sometimes using multi-factor authentication.

Project Verify also offers its own multi-factor authentication functionality, offering a replacement for other methods like SMS or email verification which, the teaser video notes correctly, have their own weaknesses.

Privacy Concerns: Phone Numbers and IP Addresses

From EFF's own Privacy Badger to Tor for Android to Safari's Tracking Protection feature on iOS, users have more options than ever before to enhance their privacy when they go online with their mobile devices. They shouldn’t have to compromise that privacy in order to secure their accounts.

Stronger alternatives than SMS and email are available now: two-factor authentication through the U2F standard or a Time-based One Time Password (TOTP) each offer superior security. Neither one is perfect on its own—both suffer from accessibility concerns, and TOTP can be abused by advanced phishing attacks. However, neither of these standards compromises the user's privacy.

One of the few things we know about the details of Project Verify is that users will be identified using a combination of five data points: phone number, account tenure, phone account type, SIM card details, and IP address.

Two of these, phone number and IP address, raise particular concerns.

Tying accounts to phone numbers has generated a growing list of problems for users in recent years, including but not at all limited to the weakness of SMS verification mentioned above. An increasingly common scam involves criminals contacting providers with the name and phone number of an account they hope to hack into and claiming they either have a new phone or have lost their SIM card. When the provider sends or gives them the new SIM and deactivates the real user's original card, the hacker is then able to use SMS-based multi-factor authentication and/or account reset tools to take over the users' accounts.

The use of phone numbers for verification can cause other sorts of problems when a phone is lost, a phone number is changed, or an employee changes jobs but a service used for work required SMS verification. In the case of a data breach, a personal phone number included in the data can expose a user to scams, harassment, or further hacking attempts.

In the U.S., social security numbers have already shown us what can happen when an assigned, nearly impossible-to-change number morphs into an essential identifier and a target for identity thieves.  Our mobile phone numbers are going down the same road as our social security numbers, with the added problem that they were never private in the first place. Let's break that link, not strengthen it.

Further, the use of IP addresses could reveal quite a bit to wireless providers or even site operators, even if you are using privacy-protective measures like Tor or a mobile VPN. Tor users in particular should steer well clear of Project Verify’s service for this reason.

For Project Verify to work, your logins to third-party apps and websites must talk to your wireless provider, whether or not you're logging in over a VPN, Tor, a local wifi network, or even using a separate device altogether. With ISPs such as those in the Mobile Authentication Taskforce given free reign to track and sell users’ usage data, it is extremely dangerous to give them even more visibility into users’ logins on or off their network.

The Project Verify site states, "The platform will only share consumers' data with their consent." However, this still leaves a lot of wiggle room for carriers. Will consent be obtained through explicit and granular opt-in Project Verify functions, or will this be one the many forms of consent buried in the user's subscriber agreement with no clear avenue for opt-out? Users should not have to worry about their data being collected by a third party simply to enable a more secure means of managing logins.

Ironically, we can't verify much about the project. What we know is that it's asking us to allow the same mobile carriers responsible for enormous, and intentional, privacy failures to become the gatekeepers of identity authentication in an attempt to combat a real problem with a solution that's both concerning and conveniently beneficial to them—which, if history is any indication, is a verifiably bad idea.