This week, I wanted to focus on going beyond passwords and talk about 2FA. Per the title, not just any old 2FA but U2F and in particular, Google's Advanced Protection Program. This post will be partly about 2FA in general, but also specifically about Google's program because of the masses of people dependent on them for Gmail. Your email address is the skeleton key to your life (not just "online" life) so protecting that is absolutely paramount.
Let's start with defining some terms because they tend to be used a little interchangeably. Before I do that, a caveat: every single time I see discussion on what these terms mean, it descends into arguments about the true meaning and mechanics of each. Let's not get bogged down in that and instead focus on the practical implications of each.
2FA, MFA, 2-Step
They may all be familiar, but there are important differences that warrant explanation and we'll start with the acronym we most commonly see:
2FA is two-factor authentication. For some quick perspective, a password alone is 1FA in that when you authenticate merely by entering a secret, all you require is one factor - "something that you know". If someone obtains the thing that you know then it's (probably) game over and they have access to your account. Adding a second factor typically means either requiring "something that you have" or "something that you are". The former is a physical device, for example I had one of these old RSA tokens more than a decade ago back in corporate land:
When I logged onto the work VPN, I needed to enter not just my Active Directory credentials but also the 6-digit number shown in the token above known as a time-based one-time password (TOTP). The bars on the left of the LCD screen would count down after which the digits would be rotated and I'd need to enter a different TOTP when authenticating. This was a pretty solid way of doing auth, albeit a bit clunky and still not foolproof. For every good security solution, someone will always find a way of screwing it up:
When it comes to "something you are", we're talking biometrics so think fingerprints, face, etc. Requiring, for example, both a password and a fingerprint would be a 2FA implementation.
Here's a very consumer-friendly way of describing 2FA: withdrawing money from an ATM requires two factors being your bank card (something you have) and your PIN (something you know). The bank card alone is useless as is the PIN; it's only a combination of the 2 that is usable.
MFA is multi-factor authentication. Strictly speaking, 2FA is MFA in that obviously, it's more than one factor. It's a subset of MFA. In consumer-facing implementations, most MFA is 2FA such as the RSA token example above. Same again with verification via SMS (don't lose your minds just yet, I'll come back to this). But, of course, MFA could also be 3FA and combine all the above factors, or even 4FA using an additional factor such as physical location.
A good example of this is the two-step authentication required by Gmail. After providing the password you've memorized, you're required to also provide the one-time password displayed on your phone. While the phone may appear to be "something you have", from a security perspective it's still "something you know". This is because the key to the authentication isn't the device itself, but rather information stored on the device which could in theory be copied by an attacker. So, by copying both your memorized password and the OTP configuration, an attacker could successfully impersonate you without actually stealing anything physical.
You'll also regularly see arguments stating that what many consider to be 2FA is really just 2-step. For example, if you physically have someone's mobile phone in your hand and it's unlocked, you could login to an account by initiating a password reset, receiving the email in their email client then entering the "2nd factor" token sent via SMS or generated by a soft token app on the device. Using a soft token generated on your phone per the Stack Exchange explanation is, strictly speaking, not 2FA. 1Password has a great explanation of this (it's worth reading the entire "Second factor? No" section of that page):
We need to make the distinction between one time passwords and second factor security. One time passwords are often part of second factor security systems, but using one time passwords doesn’t automatically give you second factor security. Indeed, when you store your TOTP secret in the same place that you keep your password for a site, you do not have second factor security.
That's not to say that this model is "bad" and by any reasonable definition, it's a massive improvement over 1FA that would prevent the vast majority of account takeover attacks I see today. But many arguments have already been had about these definitions and as I said earlier, I don't want to get bogged down in that, let's talk specifics instead. Let's talk about what makes for good authentication practices.
The Hierarchy of Auth
I want to go through 5 separate levels of auth using common approaches, explain briefly how they work and then some common threats they're at risk of. Let's start somewhere familiar:
Password alone: This constitutes a single factor of auth and if someone else gets hold of it then there's a very good chance you're going to have a bad day. Passwords suffer from all the problems you're probably already aware of: they're often weak, they're regularly reused and they're also readily obtainable through attacks such as social engineering (phishing, smishing, vishing, etc.)
Password and SMS: I see a lot of derogatory comments about this pattern but let's be clear about one thing: a password and an SMS is always going to be better than a password alone. Those derogatory comments often relate to the prevalence of SIM porting where the attacker manages to port the victim's number to their own device and are subsequently able to receive SMSs destined for the victim. It's most damaging when account recovery can be facilitated via SMS alone (i.e. forgot password so recovery instructions can be sent via email or SMS).
Password and soft token: A very popular approach these days and it leverages an app such as Google Authenticator or Authy to generate the TOTP. The SIM porting risk is avoided (if you configure it properly), plus there's not the dedicated hardware dependency of the likes of an RSA token and consequently not the financial burden of acquiring hardware devices. This is probably the best balance of security, usability and cost we have going for us today.
Password and hard token: A similar situation to soft tokens but it requires a physical device which meets even a strict definition of 2FA. It addresses weaknesses with how many people configure soft tokens but it also introduces a cost barrier and requires you to have it physically present. It's also not immune to phishing: if a victim enters their first factor (password) into a malicious page and the attacker then requests the TOTP and (quickly) uses those on the target site, you've got a problem. Oh - you're still laughing about the webcam pointed at the tokens from earlier, so here's another one complete with instructions on how to set it up and even OCR the digits on the token:
Password and U2F: This is where I want to focus on the remainder of this blog because it solves all the problems raised above with the other approaches. Let's drop straight into understanding what U2F does and why you want it.
is an open authentication standard that strengthens and simplifies two-factor authentication (2FA) using specialized Universal Serial Bus (USB) or near-field communication (NFC) devices based on similar security technology found in smart cards.
I suspect a word that's more familiar to most people is YubiKey:
YubiKey is a popular implementation of U2F and per the Wikipedia piece above, both Yubico and Google were responsible for the original development of it. The standard is now managed by the FIDO Alliance (Fast IDentity Online) and you'll see that name appear again as we progress. FIDO has released protocols that not only allow U2F devices like the one above to communicate over USB, but also over Bluetooth and NFC.
The value proposition of a U2F device like the YubiKey is that not only must you have it present ("something that you have"), it's not subject to the TOTP being disclosed like with tokens that require the user to enter a password into a third-party service which could still be a phishing page. (You also don't get very far by pointing a webcam at it!) There's a lot more to them than that, but for the purposes of this post it solves the phishing problem.
All of this so far has just been to establish the problem with various means of authentication and to talk about the solution that is U2F. Let's move onto Google's use of it.
Google Advanced Protection Program
There was actually an incident that led to this journey down the U2F path and it relates to this:
Can any friends at Google assist with an account recovery? A relative has lost access to their Gmail and recovery account and has run into a bit of a dead end options wise.
This genuinely was a relative (no, not "a friend"!) and they'd been locked out of their account and no longer had access to the old email address that was used for recovery. At about that time, they received a notification saying that their Google password had been changed and they subsequently lost access to their Gmail. On the face of it, things looked bad and whilst I'd be inclined to reach the same conclusion that you probably already have in reading this, they also had SMS-based 2FA turned on and still had access to their mobile account. I assumed it was then either a case of someone phishing the TOTP sent via SMS or.... they'd inadvertently changed the password and locked themselves out. It turned out to be the latter, but it really got me thinking more about Google account security.
During the process of recovering their account, I spent a bit of time reading about Google's Advanced Protection Program which goes beyond SMS-based 2FA (or 2-step or whichever term you wish to use) all the way to U2F. The 2-minute video below is a pretty good summary of what it's about:
I decided to go through the process myself, putting myself in the shoes of the normal everyday consumer who'd be interested in turning on a feature like this so in other words, simply following their instructions (more on alternatives later on). Also, just to be clear, Google's Advanced Protection goes beyond just 2FA via U2F; there are also controls it turns on around the types of apps that can interact with your account and changes to the way account recovery works should you ever need to go down that path.
First up, you'll need 2 U2F keys where one will act as a primary and the other a backup. Plus, one will slot into a USB socket whilst the other will connect to a mobile device. Google linked me straight through to a 2-in-1 bundled offering on Amazon by Feitian for $40:
Feitian is a Chinese company that builds a bunch of different hardware security products. The white key above is their MultiPass FIDO unit in that it works across multiple communication protocols: USB, NFC and Bluetooth. The black key is their ePass FIDO and whilst compact, only supports USB so you're never going to be using this on, say, an iPhone (at least not without an additional dongle). You can use other keys but again, I wanted to go down the "follow the instructions" consumer route and experience the process as a normal everyday non-techie would. I'll ultimately be using these on both PCs and iOS devices so the Feitian route also aligns with Google's FAQ on keys:
I ended up needing to order them via eBay instead of Google's recommended Amazon item (thanks screwy Aussie GST laws), but it's the same product and a week later, it was on my doorstep:
So let's get into it! Kicking off on the enrolment page, first, you have to (re)auth to Google:
And just as a reminder, you need the keys:
Clicking the "enrol" button, it's now on (and I also get an email confirming this), but the keys themselves have yet to be enrolled:
I already have the keys so let's register them:
For the first key:
Key goes in and I tap:
Chrome then pops up and asks for access to the key:
The key is registered so now give it a name:
Job done! I add the second key in the same fashion, albeit at the end of the provided micro USB cable:
I name that one appropriately:
Both keys are now successfully registered:
Now we turn it on:
And just in case you got all this was by accident, are you really really sure?
I'm well and truly signed out, both on google.com and in Chrome which now shows a status of "Paused":
I click the sign in link and fill the password from 1Password after which I'm faced with the second factor challenge:
I insert the ePass key, tap the button and wait:
And I'm back in!
I repeat the process for my two laptops, no dramas. This is actually much easier than either SMS or TOTP solutions which require you to re-enter a number into the page whilst the clock is counting down. One of those rare moments where more security also means more usability! Seriously, signing in once this is setup is dead simple, but that's just the PCs so far, let's do the mobile things.
Over on the iPhone, I've been signed out of the YouTube app so let's use that as a starting point:
Once I attempt to sign in, the Google Smart Lock app makes an appearance:
At least on iOS, auth'ing back into your Google account requires the Google app. No biggy, grab the app and begin the pairing:
Now because this is an iPhone without a USB socket, I'll be using the MultiPass unit with Bluetooth to auth the phone so I grab that and follow the instructions:
Once the key is in pairing mode, it shows up in the Google app with its 6-character identifier:
This same identifier is on the back of the key. Speaking of which:
And then finally, Apple pops up a native challenge that identifies the key via the same 6-letter name as before and asks for the PIN:
And we're done!
The sign-in over in the YouTube app can now use Google Smart Lock and I'm back into the account. Repeat the same thing on the iPad and all the mobile devices are now successfully auth'd.
Google's implementation is just lovely. It's fast, easy and for most people, something they're going to do very infrequently anyway. Gmail users are the big winners out of all this: as I said earlier, email is the skeleton key to your life and at least for tech folks who understand the importance of protecting accounts, this seems like a no-brainer. I wouldn't want to have to go through account recovery because I get the distinct impression that it wouldn't be a fun experience, but that's also kinda the idea: gaining access to an account without sufficient identity proof should be hard! This is why the SMS porting thing is a real problem; the number alone should never be used for account recovery because being in control of just a phone number simply isn't enough to verify identity with any reasonable degree of confidence.
There's an increasing array of other services out there that enable 2FA using U2F too, including:
As I mentioned earlier, this was really "the consumer" path to U2F on Google. There are other U2F keys out there and I mentioned YubiKey earlier on. They've just launched the 5 series which is a pretty slick implementation that includes iPhone / iPad compatible NFC and supports FIDO2. But it's also $45 for one key and you're still going to need another one to enrol in Google's U2F program.
Lastly, let me leave you with anecdote related to going beyond 1FA: I recently had someone contact me and complain that GitHub was warning them about their choice of passwords following their integration with my Pwned Passwords service. "I should be able to use any password I want", he lamented. "I've got 2FA turned on so what does it matter?!" Now, hopefully the problem here is already self-evident but let's just be crystal clear anyway: adding a second step to authentication should not be seen as an excuse to weaken the first step. I'm hesitant to call this guy's approach 2FA (if it's true MFA at all), it's more like 1.5FA or something thereabouts. The point is, use the approaches above as additional security controls, not as an excuse to weaken existing ones!
Extra advances for Spire. They’re very high-concept, utterly bonkers, and I’m unreasonably pleased with them. Even if you don’t intend to play Spire, and you should, it should be easy to follow this.
The World Yet to Come is neither a god nor a demon. It doesn’t have cultists or worshippers. It has usherers. It is an impossibility, and it needs you to make it possible. It speaks to you in death and offers rebirth. The conversation you remember is an attempt to understand that which cannot yet be understood.
It looked angelic, made of feathers and glow, but only when you faced it and only when it was still. When you tilted your head even slightly, or when it shifted, you saw behind the exterior. You saw the countless jutting blades made of merciless hard light that formed the beautiful visage. You stood immobile and prayed it do the same.
What is it? You remember it saying some called it Phoenix. It certainly likes avian metaphors. It is the World Yet to Come, and you can no more comprehend it than a chick within an egg can comprehend the skies.
What does it want? You remember it saying it will be born when the World That Is dies. It wants you to be the beak that pierces the shell and ushers in the new existence. You remember it asking if it is a perfect world you live in. You know your answer.
What does it offer? Birth.
What will it cost? Death.
You don’t remember if you agreed to be the usherer of the World Yet to Come, but you do remember dying. Yet you are here, in this imperfect world. Time to break its shell.
REQUIREMENT: Die. Dream of Phoenix. Be reborn.
REFRESH: Kill someone or destroy something with eschaton (see below), excising them from the World Yet to Come.
Usherer advances and abilities give you thin branching scars, like cracks in a shell, through which the light of the World yet to Come occasionally shines. Keep track of how many scars you have. Once at any time during a session, and whenever you use IT IS NOT YET TIME or IMMANENTIZE THE ESCHATON, the GM rolls a d10. If the result is less than the number of scars you have, you suffer a special fallout. Its severity depends on the number of scars you have. This fallout doesn’t clear any of your stress or remove any scars.
MINOR – LIGHT: [Scar] Your scars light up, shining even through clothing. For the remainder of the scene it is all but impossible for you to not draw everyone’s attention.
MODERATE – BLAZE: [Scar] The light from your scars turns sharp, shredding your clothes, then hot, immolating what’s left of them. For the remainder of the scene you blaze with the fury of a future world eager to be born. You are unharmed by this flame, which is not at all true for anyone next to you.
SEVERE – GLIMPSE: [Scar] You catch a glimpse of the World Yet to Come, and someone you’re looking at right now isn’t in it. You have to do everything in your power to excise them. If you fail for any reason, e.g. they die due to other causes, you immediately suffer 1d8 Mind stress.
IT IS NOT YET TIME. [Divine] Your wounds close. Your body opens. Once per scene, clear d6 Blood stress. A scar forms over the wounds you had, replacing ruined flesh with light.
IMMANENTIZE THE ESCHATON. [Divine] The future murders the past by your hand. Gather its light. Hold the blade. Usher in the new world. The cracks on your body grow wider – gain another scar. With a sweep of your hand, you can gather the light shining through these cracks into a blade called eschaton. The more scars you have, the harder the light, the sharper eschaton is:
Eschaton disappears as soon as you let go of it. Take note of everyone and everything you excise using it.
IT IS TIME. [Divine] You won’t be able to contain it much longer. The World Yet to Come will be born through you. The light shines brighter. Another scar forms. At any moment, even between taking stress and rolling for fallout, you can choose to shatter in a blinding flash of light. You die. Roll a d10. If the result is greater than or equal to the number of scars you have, the World Yet to Come is yet to come. Otherwise, you are reborn, scar-free and stress-free, in the same spot in the new World That Is.
The World That Is has never had anyone or anything excised with eschaton. The whole group should work together to figure out what that means.
The World That Is is not The World Yet to Come. It is an incremental step, an egg within an egg. Can you break through the infinite cycle of death and rebirth? Will piercing the Heart of Spire with eschaton release the Phoenix from its egg? Will it turn Spire itself into an eschaton, aimed to pierce the sky shell of the world?
I was re-reading Bill Gates’ Trustworthy Computing Memo, when I came across an apparent anachronism: a reference to the attacks of September 11th, 2001. I was certain that the memo predated 9/11. A doubletake at the timestamp confirmed that Gates sent it out January 15th 2002.
But the two events were definitely flipped in order in my mind, and I wondered if I was the only one. So I started asking friends who have been working in computer security for over 20 years for their gut instinct: what came first, the Trustworthy Computing Memo or 9/11? The results have been nearly unanimous. Almost everyone who was already working as a security engineer at the time is convinced the memo came first.
I have a theory for this time warp. 9/11 still feels like recent history. It was something that happened during our generation — we were all adults at the time. Gates’ memo, on the other hand, feels like something from the predawn of time. It marks a point when the industry formally acknowledged the importance of product security. It was a watershed moment that effectively marks the beginning of life for our professional generation. It as our AD 1, and in our minds it predates all modern history.
Crooks who hack online merchants to steal payment card data are constantly coming up with crafty ways to hide their malicious code on Web sites. In Internet ages past, this often meant obfuscating it as giant blobs of gibberish text that is obvious even to the untrained eye. These days, a compromised e-commerce site is more likely to be seeded with a tiny snippet of code that invokes a hostile domain which appears harmless or that is virtually indistinguishable from the hacked site’s own domain.
Before going further, I should note that this post includes references to domains that are either compromised or actively stealing user data. Although the malcode implanted on these sites is not designed to foist malicious software on visitors, please be aware that this could change at a moment’s notice. Anyone seeking to view the raw code on sites referenced here should proceed with caution; using an online source code viewer like this one can let readers safely view the HTML code on any Web page without actually rendering it in a Web browser.
As its name suggests, asianfoodgrocer-dot-com offers a range of comestibles. It also currently includes a spicy bit of card-skimming code that is hosted on the domain zoobashop-dot-com. In this case, it is easy to miss the malicious code when reviewing the HTML source, as it fits neatly into a single, brief line of code.
Zoobashop is also a presently hacked e-commerce site. Based in Accra, Ghana, zoobashop bills itself as Ghana’s “largest online store.” In addition to offering great deals on a range of electronics and home appliances, it is currently serving a tiny obfuscated script called “js.js” that snarfs data submitted into online forms.
As sneaky as this attack may be, the hackers in this case did not go out of their way to make the domain hosting the malicious script blend in with the surrounding code. However, increasingly these data-slurping scripts are hidden behind fully fraudulent https:// domains that are custom-made to look like they might be associated with content delivery networks (CDNs) or web-based scripts, and include terms like “jquery,” “bootstrap,” and “js.”
Sometimes, the malicious domain created to host a data-snarfing script mimics the host domain by referencing a doppelganger Web site name. For example, check out the source code for the e-commerce site bargainjunkie-dot-com and you’ll notice at the bottom that it pulls a malicious script from the domain “bargalnjunkie-dot-com,” where the “i” in “bargain” is sneakily replaced with a lowercase “L”.
In many cases, running a reverse search for other domain names where the doppelganger domain is hosted reveals additional compromised hosts, or other methods of compromising them. For example, the look-alike domain bargalnjunkie-dot-com is hosted on the address 22.214.171.124, which is the home to several domains, including payselector-dot-com and billgetstatus-dot-com.
Payselector-dot-com and billgetstatus-dot-com were apparently registered so that they appear related to online payment services. But both of these domains actually host complex malicious scripts that are loaded in an obfuscated way on a number of Web sites — including the ballet enthusiast store balletbeautiful-dot-com. Interestingly, the Internet address hosting the payselector and billgetstatus domains — the aforementioned 126.96.36.199 — also hosts the doppelganger domain “balletbeautlful-dot-com,” again with the “i” replaced by a lowercase “L”.
A “reverse DNS” lookup of the IP address 188.8.131.52, compliments of Farsight Security.
The malicious scripts loaded from payselector-dot-com and billgetstatus-dot.com are obfuscated with a custom HTML function — window.atob — which scrambles the code referencing those domains names on hacked sites. While the presence of “window.atob” in the source code of a Web site is not itself an indicator of compromise, a search for this code via publicwww.com is revealing and further review suggests there are dozens of sites currently compromised in this manner.
For example, that search points to the domain for online clothier evisu-dot-com, whose HTML source includes the following code snippet:
If you cut and paste the gibberish text that’s between the quotations in the highlighted portion of the screenshot above into the site base64decode.net, you’ll see this jumble of junk text decodes to apitstatus-dot-com, yet another dodgy domain custom-made to look like a legitimate function of a regular e-commerce site.
Revisiting the source code for the domain balletbeautiful-dot.com, we can see that it also includes this “window.atob” code followed by some obfuscated text. A paste of this gobbledegook in Base64decode.net shows that it decodes to…you guessed it: balletbeautlful-dot-com.
Sometimes, antivirus products will detect the presence of these malicious scripts and block users from visiting compromised sites, but for better or worse none of the sites I mentioned here currently are flagged as malicious by any of the more than five dozen antivirus tools at the file-scanning service virustotal.com.
Another security company — RiskIQ — has written extensively about these attacks and has attributed several recent compromises — including the hack of Web sites for British Airways and geek gear vendor Newegg — to a group it calls “Magecart.”
It’s unclear if the compromises detailed in this post are related to the work of that crime gang. In any case, I like RiskIQ’s comparison of these attacks to ATM skimmers, a type of crime that has held my fascination for years now.
“Traditionally, criminals use devices known as card skimmers—devices hidden within credit card readers on ATMs, fuel pumps, and other machines people pay for with credit cards every day—to steal credit card data for the criminal to later collect and either use themselves or sell to other parties,” RiskIQ’s Yonathan Klijnsma writes. “Magecart uses a digital variety of these devices.”
I like the comparison to skimming because online merchants are being targeted in major way right now precisely because of efforts to make it hard for thieves to make money from fraud involving counterfeit debit and credit cards. The United States is the last of the G20 nations to make the transition to more secure chip-based payment cards, and virtually every other country that has already been through that shift has seen a marked increase in online fraud as a result.
Heads up to anyone responsible for administering a Web site: There are options available to help monitor your Web site for unauthorized changes. Tools like Tripwire and AIDE can detect new or modified files, but many of these formjacking attacks involve the insertion of code in existing Web pages. Subscription services like wewatchyourwebsite.com and watchdo.gs may be more helpful here.
In case anyone’s wondering, all of the hacked sites mentioned here have been notified. In many cases, the contact details for the owners of these sites is hidden behind WHOIS privacy protection, and alerting victims via Facebook or filling out contact forms elicits no response. In other instances, the alerted site cleaned up part of the compromise but left key malicious elements intact — without even acknowledging efforts made to notify them.
I realize that this post is quite a bit more technical than most at KrebsOnSecurity. I’m explaining my process for finding these sites because there appear to be so many compromised by these methods that the only feasible way to get them cleaned up quickly may be to crowdsource the effort, given that more online shops are being newly compromised each day.
I burned through several days this week following the virtual rabbit holes dug by whoever is responsible for this ongoing e-commerce crime spree, and it seems to me that finding and alerting all the compromised businesses could keep an entire team of people busy for some time. But I am just one guy, and this is a thankless task.
KrebsOnSecurity would like to thank @breachmessenger for their assistance in researching this story.