You’re woken in the night by your work phone buzzing on your nightstand, the full-brightness screen bathing your bedroom ceiling in cold light as the gaudy default ringtone drags you to your feet. Your partner rolls over and quickly goes back to sleep mumbling something that sounds like “you better get paid for this”. The cat looks at you as if this was somehow your fault. Maybe it is. You look at your clock, the dim red seven-segment display reading 3:04 in the morning. You’re an on-call engineer, third line support so you only get called if something is really broken.
“Hey, what’s up?” you ask, answering the call and quickly moving into the corridor and shutting the door to not disturb your partner even more. “Hey it’s James from support”. You have no idea who James is, you’ve never spoken to them, but you think you’ve seen them on Slack before. You’re not familiar with anyone in the support team for this time zone either. What time zone is even awake right now, you wonder as you head towards your home office, flicking on the light and temporarily blinding yourself.
“Uh, okay hi James. What’s the issue?” you ask, blinking as your eyesight adjusts.
“I think we’ve got a database problem, we’ve been keeping an eye on increased 500 error rates at the load balancer, and the database instance CPU usage is pegged at 99%. We were hoping to leave it until you all woke up, but it’s reaching the point where we’re getting worried an—”
“Yeah okay okay, let me look.” you say sharply, cutting them off. That was perhaps a little too sharply, you make a mental note to apologies later when you’ve woken up. You open your laptop and check your email for alerts.
“Okay, what am I looking at? I don’t see any alerts.” you ask, scrolling through your email inbox and seeing nothing but a few GitHub notifications and an all-hands video call invite.
“They’ve not triggered properly but I can see the error rates on the dashboard. Just a moment… I’ve emailed you a direct link to the right dashboard to see what I mean.”
Your laptop makes an obnoxiously loud email notification sound. Sighing and making a mental note to find out how we managed to break monitoring alerting, you open up the email and click the link to the dashboard. The screen flashes a few times in the usual redirect dance as you get pushed over to your single sign-on login page.
“Hold on…” you say, propping up the phone with your shoulder as you go to sign in. Tapping in your email address and password. Usually it pre-fills your username, but this time it didn’t. Maybe there was a browser update that cleared the cache. It’s a problem for later, you think, as you finish typing your password and click ‘Sign In’.
There is no panacea for security. But if there’s one single thing that would improve your security right now — then it’s using a security key for your two factor authentication 1 instead of a time-based code, push notifications, or text message.
Most organizations have adopted some form of two factor authentication, or “2FA”, already — but of all the common options security keys stand out at preventing some of the most sophisticated phishing attacks that other methods are vulnerable to. To see why, we’ll do a deep-dive into how 2FA works and why a security key stops attacks that other methods cannot.
What is a security key?
Security keys are a generic name for devices like the Yubico Yubikey or Google Titan Security Key. To be precise we’re talking about any device that implements either the FIDO Universtal Second Factor (U2F) 2 or FIDO2 standard. 3
So why are these better? It might feel because the device is somehow ‘hardened’ or ‘cryptographic’ — whatever that might mean. To an extent that’s true, these manufacturers spend a lot of time and effort making these devices tamper-resistant, and public key cryptography plays a role. But that’s not why they’re better for 2FA. To understand, we have to look at how they work.
Logging into things
When you log in you go to your login page, say https://login.example.com, and enter your username and password. Then, you have to pass the 2FA prompt. If you’re using a text message, you’ll have to find your phone and enter the code it sent you. If you’re using a time-based code you’ll have to find the code (which might be on an app on your phone) and type that in before it changes every 30 seconds. If you’re using a push notification you’ll also have to find your phone and tap ‘yes’ on some pop-up notification and your browser will magically let you in. If you’re using a security key you’ll have to dig it out of whatever pocket you left it in, plug it in, and tap it.
In the background, the site logs you in 4 and issues you with a cookie (remember those cookie banners, EU readers) that identifies you so you don’t need to log in again for a while.
To a user, these all feel very similar. You have to go find something (your phone or the key) and do some interaction to make it work, then you go about your day. To demonstrate how they differ, we need to consider what it looks like when you’re phished.
A phishing attack is where an attacker (someone trying to get into your user account for whatever nefarious purpose they have in mind) tricks you into giving up your login details. This can be as simple as getting an unannounced call from someone claiming to be “IT” saying “I need your password to make sure your computer works”, to as complex as a highly personalised and targeted social engineering attack against a specific individual.
Often, in order to actually gain access to your account, the phishing attack will direct you to a login page to log in to something. They might do this by emailing you a link to a document, or posting it on social media. The trick is that instead of login.example.com, it’s got a very similar, but not identical name which is controlled by the attacker. The goal is to make you, the user, not realise it’s a fake site. It looks just like your real site (they copied the layout to be pixel-perfect), it even works if you try to log into it. But the attacker controls it, and is using it to steal your login details.
You might think ‘I would never fall for that’. But statistically speaking someone will. Sophisticated and motivated attackers can be very, very good at manipulating people into doing what they want.
Why are TLS certificates such a hot commodity on the dark web?
Hijack on the digital high seas
Let’s go back to our story. The person you’re talking to is an attacker — a well motivated, well informed, and well equipped one. They’ve scraped what information they can about you, and your company from the internet. They know that ‘James’ is a real employee, and enough about him to impersonate him — to you at least. The email isn’t from a real company email, the dashboard link was wrong, and it redirected you to a fake login page. But you didn’t notice. They found out what the real URLs are 5 and intentionally setup fakes that look similar.
The combination of just enough right to make you trust them, a well-practiced delivery by a professional attacker, the time of day, and the sense of urgency all came together.
If you don’t have 2FA, you’ve already lost. You enter your username and password. The attacker relays those to the real site, and gets back a cookie which they pass back to you along with redirecting your browser to the real dashboard site. 6 This is automated, and happens in a matter of seconds.
If you’re lucky enough to have 2FA, the attacker gets a 2FA prompt flash up on their real login site. Not a problem. They just make the fake one show the same thing. 7 If you’re using a text message or a time based code, you type it in, and once again the attacker copies it into the real page and completes the login. It’s the same with push notifications, the user gets a pop-up on their phone asking if they’re trying to log in. But they are trying to log in, so they hit ‘accept’, and the attacker is successfully logged in.
After clicking ‘sign in’ the screen redirects again this time with the familiar ‘Confirm on your phone’ prompt. “Hold on James…” you say, taking the phone from your ear to tap the push notification. ‘Are you trying to sign in?’ it asks. Blearily, you tap ‘Yes’. In your tired state, you miss the part where it says ‘…from a new device’.
After a moment the screen redirects again, and you end up on the dashboard, showing totally normal metrics across the board. “Hrm… I can’t see anything wrong…” you begin, expanding the time period to look for any issues further back.
“Oh… Oh I’m so sorry. I was looking at the dev instance dashboard” the person down the phone says with surprise. With a groan and an eye-roll you hope wasn’t audible, you ask “So… there is nothing wrong.”
“No, production is fine. I’m so sorry I woke you. Get some sleep, I’ll write up a change to the support run book to make sure we check this before escalating. Good night.” They hang up before you can tell them off. You take one last look at the dashboard to make sure everything is green, and call it a night. Flicking off the light you trudge back to bed. ‘Sometimes these things happen’, you think, trying to convince yourself to not be too upset at a simple mistake
At 8:30am you wake up to your alarm, and hundreds of emails. The production instance was compromised overnight. The security team have invoked their incident response protocol and locked out nearly everyone with production access while they assess what happened. They say they’ll have a damage assessment before lunch, but from talking to your colleagues it sounds like a full production database leak.
Your phone goes again, this time it’s the CISO. 8 You’ve not spoken to her directly before, so you’re a little taken aback.
“Uh… hey Sarah. How can I help you?” you say nervously
“Hey, I wanted to ask you — did you log in last night. At… 3:12 am?” she asks.
“Uh… yeah I think so. I was on call. There was a support call. I checked a dashboard.”
A few seconds of silence is all it takes for you to realise how wrong things have gone, and what’s happened. “You should come into the office. Bring your laptop.” she says, and hangs up.
Under lock and key
With a security key, things are different.
After clicking ‘sign in’ your browser flashes up the ‘plug in and tap your security key’ prompt as normal. In your sleep-deprived state you nearly drop your keys as you get them and plug them in. “Hold on James… I need to find my damn key…” You tap the side of the security key and… nothing. Nothing happens.
“Huh… why can’t I log in…” you ask. You tap the key a few more times incredulously, wondering if it’s somehow broken.
The attacker on the phone with you, realising what just happened, makes an excuse. “Oh, sorry! I’m looking at the wrong dashboard. My mistake!” and promptly hangs up. Frowning you try to go to the dashboard site directly, and try again, that one does work. You check, and production is indeed fine.
Rolling your eyes you draft an annoyed email about support escalating without checking things, and decide to leave it until the morning to send. No point getting angry at someone now, you reason.
In the morning, better rested and with a cup of coffee you realise that the login was a fake one, that the email was an attack. “Oh…” you say slowly as realisation dawns. Quickly, you find the security incident emergency number and call it.
After a few nail biting minutes of seeing yourself get locked out as security disable your access as a precaution, you end up talking to a member of the security team. “I can see a login attempt at 3:12am. It says the 2FA prompt timed out. Then another login attempt two minutes later at 3:14am, that one was successful” she continues, clicking through the access log on her laptop.
“Yeah that second one was me checking the dashboards normally… I used my bookmark link for that one.”
“Okay, It looks like your account hasn’t done anything else since this morning. I don’t see any evidence of compromise.”
You breathe a sigh of relief.
“We’ll reset your password and force sign-out all sessions as a precaution.” the security engineer continues “If you used that password anywhere else you should change it there too. You should be back online in a few minutes.” You go through password reset on the phone, thank her, and hang up.
After taking a coffee break to try to relax after your stressful morning, you see an email from the security team to everyone. Reminding people to be on the lookout for phishing attacks, and that security stopped a near-miss recently. They’ll have a incident report out within a few days.
Thankfully, it doesn’t name any names.
How do security keys work, really?
So what happened, why did the key not do anything? How did it know something was wrong?
We have to understand how they work. 9 We’re going to talk about a FIDO U2F key here, but the same principals apply to the newer FIDO 2 / Webauthn 10 protocol (and many security keys on the market support both).
FIDO U2F requires browser support. The browser exposes an API through Javascript that allows a website to request a U2F registration (when first enrolling the key) or a signing (as part of a login). The browser then uses USB (or NFC) on the device to communicate directly with the security key. This is why the ‘present your key’ popup you see in your browser is part of the browser’s UI, and not the website’s.
The login service passes a random challenge (a random string) and the data it knows about the keys (so that the browser knows which keys, if any, to use). The browser then assembles a client data block of data, which includes the origin URL of the website requesting the signing and the challenge. The browser then computes the SHA256 hash of the client data to make the challenge parameter, and the SHA256 hash of the origin URL to make the application parameter. These are both then passed to the security key over USB.
There’s two layers of security against phishing attacks here. Some security keys literally do remember which websites they are registered to by storing the application parameter on the physical key, which is a hash of the URL. 11 If it doesn’t recognise the application parameter, then it will refuse to perform a signing in the first place.
Even if the key did sign the request this is of no help to an attacker. The challenge parameter is a hash of data which contains the origin. When the signed data is passed back to the login service by the attacker it will contain the full client data block along with the signature. The login website can then calculate the hash itself and verify if the client data refers to the correct origin, and reject the login if it doesn’t.
The trick here is that the security key, and the login service, cannot be tricked by social engineering. Even at 3:12am, even while being socially manipulated, even when you’re just not paying attention.
Let’s go back to our story and see what happened. The attacker is secretly logging into the real login behind the scenes, while presenting a fake login site to you. You’ve already entered your username and password, and the attacker has copied them over. The real login generated a challenge and passed it to the attacker along with data about the key it expects. The attacker can relay this to you and request the signing.
The fake login site requests a U2F signing and passes the captured challenge and key metadata. Your browser generates the client data block with the fake site’s URL, and uses the fake site’s URL to generate the application parameter. If your security key is a newer model it will refuse to sign anything at all. It doesn’t recognize the application parameter because it’s not been registered with the site.
If your security key is an older model, it may not know if this is a website it’s registered with or not. But even if it returns the signature and the attacker passes it back to the real login — the client data will show the attacker’s URL and not the real one. If the attacker manipulates the client data when it passes it back to change the URL, then the signature will not be correct and the login service will reject it.
In both cases the security key, web browser, and real login service together can detect phishing attacks where the attacker is actively relaying data between the real login and the user. This means that the vast majority of phishing attacks that rely on tricking a user via social engineering are impossible.
The downsides
There is no panacea for security, and security keys are the same. There are downsides.
Phishing attacks are still possible in some cases, albeit much harder. If an attacker can inject or compromise a root certificate authority on your laptop, then they can trick the browser into relaying the wrong application ID to a security key to be signed. Although if they can do that they can likely use malware on the machine to just directly exfiltrate the cookie from a legitimate sign-in anyway.
They also don’t solve other classes of attacks. Tricking a user into adding a dodgy OAuth2 application and granting it permissions to read all your email can leak data even with a security key. Same with an attacker pretending to be IT and having you install remote control software.
For large enterprises there can be hurdles too. The keys themselves are about £30–50 each, depending on the model. But with 1,000 employees finding someone to sign-off on a £30,000+ spend can be a challenge. There are logistics problems too, especially in a remote company you might need to mail them out which can be expensive and unreliable.
The bigger problem for large enterprises can be user support. Training hundreds of users on how to change their workflow to use the keys who might have never used them before. Handling users who lose or break them (they’re tough, but they’re not indestructible). It’s all but guaranteed that you’ll end up in a situation with a senior salesperson or engineer who just flew to a client site, forgot their security key a thousand miles away, and needs to be able to sign-in to give a presentation in ten minutes for a major deal.
Making the change to security keys requires a fundamental shift in how users interact with their corporate IT systems. It’s a lot of disruption for a small change. But that change just might save you at 3:12am one day.
When our experts are your experts, you can make the most of Kubernetes
Cover photo by Andre William on Unsplash
- Two factor authentication may also be called “multi-factor authentication” or MFA. MFA is a more general term, and can include more than two factors.
- FIDO U2F is also called FIDO CTAP1.
- The “FIDO Alliance” is an industry body that publishes and maintains the various standards for security keys.
- In enterprises there’s usually some complex dance with SAML or OpenID Connect (OIDC) here, but it doesn’t matter for this example — you login and you get a cookie.
- You’d be surprised how easy this is. This article isn’t intended to outline how attackers gain information, but a good example is to just look at a certificate transparency log for the targeted domain.
- Many sites have gotten wise to this sort of thing. If they detect a cookie being used in multiple locations in a way that implies a user traveled impossibly fast, then they’ll likely disconnect the user and cause an alert. But even this protection is often not fast enough, attackers can automatically do whatever actions they want quickly. It’s not a person clicking through menus to search through your email, it’s a script that adds a email redirect rule in less than a second.
- Remember, this is fully automated by the attacker.
- Chief Information Security Officer
- This assumes you know what a hash is and what signing means, in cryptographic terms.
- Webauthn is a W3C standard that describes how browsers talk with newer authentication devices. It’s used by FIDO2, but FIDO U2F generally is implemented directly by the browser. There is also a provision to use a FIDO U2F compatable device with Webauthn.
- Some keys implement ‘resident keys’ that literally stores cryptographic material per site in a ‘slot’ on the hardware. This is the most secure, but means you can only register a key with a limited number of sites. Some keys, such as modern Yubikeys, instead take a smarter approach that stores the cryptographic material with the site it’s logging into, but encrypts it so it can only be decrypted at signing time by the security key. The cryptographic material is then passed to the key by the login site as part of the signing request. But because of the encryption no attacker observing this can learn anything from it or use it themselves.