Uber is in the computer security news again, this time over allegations that its 2FA is no good.
ZDNet, for instance, doesn’t mince its words at all, leading with the headline, “Uber ignores security bug that makes its two-factor authentication useless.”
Two-factor authentication, or 2FA, is also known as 2SV, short for two-step verification.
It’s an increasingly common security procedure that aims to protect your online accounts against password-stealing cybercrooks.
When you login, you have to put in your usual password, which typically doesn’t change very often, plus an additional login code, which is different every time.
These one-time login codes are typically sent to you via SMS (text message) or voicemail, or calculated by a secure app that runs on your mobile phone.
The “second factor” is therefore usually your phone; the “second step” is figuring out and confirming the one-off password that crooks can’t predict in advance.
It’s not a perfect solution, but it does make it much harder for a crook who has just bought stolen usernames and passwords on the Dark Web: your password alone isn’t enough to raid your account.
What’s the story?
So, why is Uber’s 2FA supposedly “useless”?
According to ZDNet, an Indian security researcher has convinced them that he can bypass Uber’s 2FA, thus reducing your security back to what it was before 2FA was introduced.
So, when would you expect to see a 2FA prompt?
We’re not Uber users, but some of our colleagues are, and as far as we can tell, Uber doesn’t have an option to force on an additional 2FA check every time you login.
Apparently, Uber automatically activates 2FA only when it thinks the risk warrants it.
This approach works because fraudulent logins frequently stand out from regular logins: they come from a different country; a different ISP; a new browser; an unusual operating system; and so on.
In a few tests here at Sophos HQ in Oxfordshire, England (ironically, Uber isn’t licensed to operate in Oxford, but that is a story for another time), we were able to provoke Uber’s 2FA prompts easily enough.
For example, we were asked for a one-time code after by forcing a password reset via the mobile app:
We also tried logging in to the mobile app and then connecting via a regular browser from a laptop, whereupon we hit the 2FA system, too:
Once Uber “knew” about the laptop, the Uber servers did’t ask for 2FA codes again when we logged back in from the same computer.
Is 2FA worth it?
Uber’s “part-time” approach to 2FA seems rather self-defeating: if 2FA is worth doing, surely it’s worth doing all the time?
Unfortunately, in real life, 2FA is not as popular as you might expect: Google, for example, recently lamented that the 2FA takeup rate amongst Gmail users is still below 10%.
In other words, fewer that 10% of Gmail users have turned the feature on.
Reasons for spurning 2FA include: I don’t trust Google with my phone number; it’s too much hassle; I get locked out every time I leave my phone at home; no or poor mobile coverage in my area; nothing worth hiding anyway.
In short: convenience before security.
Uber’s approach therefore takes a middle ground common to many online services, such as Google’s CAPTCHA system: try to avoid any extra customer-facing security shenanigans whenever possible.
Simply put: there’s a school of thought that it’s better to have everyone using 2FA some of the time, ideally when it’s most worth it, than to have most people not using it at all because of its perceived problems.
Is it useless?
If you could figure out what triggers a “part-time” 2FA system and therefore learn how to trick it into misidentifying you as a low-risk login, and you could reliably do it every time, you might reasonably claim that the 2FA system concerned was useless.
But in this instance, ZDNet admitted that “in some cases the bug would work, and in others the bug would fail, with nothing obvious to determine why.”
In other words, even if the effectiveness of Uber’s 2FA is less than expected, it doesn’t sound as though it’s strictly useless.
You’d also like to think that Uber deliberately doesn’t keep the when-to-activate logic in its 2FA system static, in order to keep the crooks on their toes.
(Of course, Uber infamously tried to hush up a recent data breach by paying off hackers under the guise of a bug bounty, and sacked its Chief Security Officer during the fallout, so just how proactive its security practices are remains to be seen.)
For all that Uber has done plenty to attract well-merited criticism in the past, we’re not sure that calling its 2FA “useless” on the basis of a bug that can’t reliably be reproduced is entirely fair…
…though if we were Uber, we’d make some tweaks anyway, such as the one we suggest at the end of the article.
What to do?
Suppressing 2FA doesn’t give cybercrooks a free lunch: they still need to crack your regular password, so:
- Make sure you’ve changed your Uber password since the company’s recent breach notification.
- Pick a proper password for every account, including your Uber account.
- Don’t share passwords between accounts, or even use similar passwords that differ by a few letters that denote each account.
- Consider using a password manager so you get high-quality passwords and don’t have to commit them all to memory.
Having said all that, we do have a suggestion for Uber, and for any other online services with “part-time” 2FA that only kicks in from time to time:
- Offer an “always on” option for 2FA.
Here’s our message to Uber, and anyone else out there with what you might call “part-time 2FA”…
…there is an important minority of users out there who favour security over convenience, and who would be happy to turn 2FA on permanently, so don’t be afraid to let them lead the way!
I’m not sure why you consider “I don’t trust google with my phone number” to be convenience over security.
Not that I would trust them with my email either.
I meant to imply very much the point you just made: heck, if you’ve already trusted Google with your email (and I bet you’ve mentioned your phone number in any number of emails in recent memory – you may even have it in your email signature), is handing over your phone number for the sole purposes of 2FA really such a significant reason for refusing 2FA?
(I’m not saying it isn’t a valid reason, just that it’s probably a bit of a hollow one after signing up for Gmail in the first place.)
In other words using Google at all is convenience before security.
Hmm, maybe they need a new slogan…
Surely 2FA works with a non-smart phone too? An SMS message doesn’t require the use of a smart phone, mere a mobile/cell phone – but that has to be somewhere that has an available signal from the mobile operator – not all the land area is covered by mobile signals and many rural areas where people live and work have great difficulty getting any usable signal. So it is not necessarily a reliable form of security.
Can you elaborate on why this is a “useless” way of doing 2FA? It sounds like the system is recognizing the device and once you login from a known device you are no longer prompted for the OTP. Lots of applications across the web do this – including most of my banks; you only get prompted for the code when you are using a new device.
The reason the researcher called it “useless” is he claimed to be able to stop the 2FA part from happening at will – as though he could trick Uber’s servers into thinking he were a trusted device. But ZDNet didn’t seem to be able to replicate this.
“I don’t trust Google with my phone number” isn’t “convenience before security,” it’s security before security.
The reason I used that as a sort-of throwaway remark is that you don’t have to use your phone number to activate 2FA, so an unwillingness to give your number to Google isn’t really a reason to spurn 2FA. It’s a bit like being invited to go and see a movie and excusing yourself by saying, “No thanks, I don’t like popcorn.” Sure, a lot of moviegoers eat popcorn, but it’s not compulsory…
“Twitter will continue to play political favorites this year, as it prepares a propaganda campaign mailer that asserts to remind users that the election of the current American President was based upon so-far unproven Russian links” There I fixed the title for you.
NIST as of June of 2017 says that SMS texts don’t even meet the definition of 2FA. Too easy to steal/capture.
Google also uses similar tactics with it’s 2FA in that you don’t have to use a code EVERY time you login. It remembers IPs, locations, and machines as well, just like Uber. It does pass the NIST standards, however.
Well, I kinda see Uber’s point.
Let’s use the standard Bruce Schneier definitions. The first factor in 2FA is “What you know,” userid and password. The second factor in 2FA is “What you have,” in this case a cellphone with app. So if Uber queries the requestor and determines from the source that it’s their cellphone app and has some unique ID embedded in the app, then they’ve already satisfied “What you have.” Round-tripping a code adds nothing.
The experiment you ran seems to justify this interpretation: Codes only required when the requestor wasn’t the cellphone app.
I hate 2FA because for a long time my mobile phone wasn’t working because I was here in Mexico and getting no signal from Verizon whatsoever. It meant that I’d be unable to use UBER all the time and I’ve wasted loads of money on “regular” taxis and now I’m running out of money!! Every little bit helps!!!
You didn’t just go into a convenience store and buy a pre-paid SIM so your mobile phone would work?
I despise the assumption forced by 2FA that there can’t be people without a phone. I mean, I love my phone, but it is not uncommon that leave it a home or lend it to my wife… and when that happens, I’m screwed because 2FA doesn’t provide an alternative means of authentication when you happen to NOT have access to your phone.
Many (most?) 2FA systems provide a system of backup codes – for example if you lose your phone or your 2FA fob or whatever. (Granted, these are not usually intended for routine use but for emergencies, such as if you phone is lost or stolen.)
WordPress, for instance, makes you print out 10 backup codes as part of turning 2FA on.