Reject Passwords, Return to (Security) Keys
By Red Siege | November 28, 2023
The weakest link in your information security chain will always be the human behind the keyboard. No matter how much death by PowerPoint security training you subject your user base to. There’s always a good chance someone will create and use a weak password, accidently fall for a phishing campaign and share their password or reuse a good password that has been breached elsewhere.
Even if a user is following all the best practices, what is keeping a user from accidentally accepting the 1,000th push notification on their phone when they did nothing to require that prompt?
A security key deployed in the right manner solves this, especially in a “Passwordless” deployment. But we need to address the elephant in the room.
Everyone has a different definition of what passwordless means. I’m defining passwordless as not requiring a memorized string of characters for authentication that a user generates/controls, ideally, it’s something physical like a hardware key (something you have) that is then paired with (but not required) something unique to the user such as a pin (something you know) or fingerprint (something you have).
PassKeys are the other method of doing passwordless authentication. Traditionally they are an app or a program on your device that you own. This app requires a pin, swipe pattern, or biometrics such as fingerprint to authenticate. Additionally, this app will have to be solely bound to the device itself and will not work on any other device. We’ll have a more detailed blog post about PassKeys in the future, but this blog focuses more on hardware tokens such as YubiKey.
Traditional authentication uses shared secret key to validate authentication. Such as my password is “Passw0rdsAreB@d” is sent to the service to be validated against the store shared secret. In a perfect world this would be simply a hash of the password, not the actual password.
The “Passwordless” security key uses Public Key Infrastructure.
I’m going to give a very high level of how this works.
The YubiKey will create a unique private and public key pair for the service you are authenticating too. The public key is sent from the YubiKey to your browser and then to the service in question to store.
Not a lot honestly, and in some cases this process is way faster and easier than traditional two-factor. Which for end users that’s a huge plus. Microsoft has a great video showing how a user would gain remote access to a machine via Azure with FIDO2 (WebAuthn) Authentication. But this process will be the same for many other services.
User selects the identity they are authenticating as. (This is specific to Azure AD, but other services tend to use something similar)
The user will then selects the “Sign in with Windows Hello or a security key.”
The computer will request the user touch their key.
Then the computer will request the user to enter their pin (this part of the process is not required but highly recommended).
The user is signed in, and depending on how the DA deploys this, this could be the only time the user will need to use their key to access everything else in the Microsoft ecosystem. No passwords, just select username, touch key, enter pin, profit.
No, here’s why.
First off, the pin is not required, however, its highly recommended in the event someone physically steals the key.
This is a very extreme and equally unlikely scenario, but let’s say a hacker specifically targets your organization/users. The hacker then mugs your user and steals this key, and even more unlikely your user never notifies you that while being mugged, they had the key stollen.
Without this pin the hacker will be able to likely guess the service, login username, and just use the key to login to the user’s account. Until you unpair the key to that users account.
The magic with this pin is you can only guess up to eight times, there’s no cool down period, nothing. Eight wrong guesses and the key completely locks up. The only way you get more guesses is by guessing the pin code right. Additionally, this pin code can be set to use alpha numeric values with a minimum of six values.
Again, this is only meant to be used to deter attackers from stealing the physical key and trying to use it to authenticate as that user to those specific services, before the IT staff has a chance to react. Back to the real world.
Keys and locks have been in human history since the early Egyptians wooden locks. Everyone knows a key unlocks something you want.
A physical key that people need to just plug in and touch, is way easier to manage and get buy in than “Okay, on your personal device you need to download this exact app, connect it to your user information, and then quickly copy the code over before it expires.” concept.
Most security user friendly solutions are paved with good intentions. The push notification way of two-factor authentication is trying to free users of SMS codes, rotating codes in applications by only requiring them to respond to a simple “Push big button to approve the login”.
The hacker new hotness is, once an attacker gets valid credentials, it takes literally no skill to spam the authentication to send tons of push notifications to the user hoping that the user will just accept the push notification to make the app stop. Easily “bypassing” two-factor.
A security key solves this issue, with minimal overhead. Let say you haven’t gone for the passwordless solution, but you are using the key as a 2nd factor. Well even if the attacker guessed the right credentials, the attacker would only ever be the one to see the prompt for the insert and touch the Yubikey. The end user never gets any prompts to do anything.
This is incredibly powerful feature. Ealier we mentioned that the service will send back to the security key a challenge and the origin (usually the address of the website).
In the event of a phishing campaign specifically tries to capture the security key process, it will not matter. The attacker will not be able to do anything.
The attacker (unless they have control of that targeted domain which why would they even bother phishing users for their security key authentication) would need to set up a separate domain to mimic what the user is authenticating too. This will fail because the attacker would have to forward that challenge with their fake domain, receive the encrypted challenge response from the user and forward it to the actual service.
This will always fail because the domain is wrong, the origin will always use the attackers fake domain. When the valid service tries to decrypt the received challenge, the challenge will have the wrong domain. The hashes won’t match, and the service will reject the whole authentication attempt.
If you go passwordless with the security key solution, the key uses PKI to handle the passwords. It doesn’t make sense to lecture users about a password they don’t get to create or control. The pin is a “none” issue because of the very unlikely scenario mentioned earlier. Training time can be spent elsewhere now.
Password managers were the solution to hard to guess (and remember) passwords. The thing that effectively killed this is many people use multiple devices to sign in and use said hard passwords. The solution was making vaults and storing them with a 3rd party, that must be online at all times. This is all great as long as the third party never gets breached…
The Yubikey is all of this, but instead of it stored online at all times, you only ever use it when you need to authenticate to.
None, this is a perfect solution to all of our password security woes. However, you might want to consider the following…
If the user loses control of their key, be it theft, misplacing it, or just general wear and tear. Once the key is no longer useable, they will not be able to log into their account. Most common recommendation is to assign a 2nd backup key in the event the first one fails.
I’ve had my YubiKey for about 4 years now attached to my key ring. I’ve never misplaced my Yubikey, and it still works despite it being on my keychain inside my pocket for years on end.
Most security key solutions will just never be cheaper than an authenticator app. Especially if you end up assigning an additional backup key to each user. Hence why only the largest corporations have gone with these solutions. Good news is as more and more technologies and companies adopt this technology it’ll continuously get cheaper to purchase. Right now just for an individual they’re running $50 a key. For an individual concerned about security I’d still argue this is absolutely worth it, might be a harder sell for an enterprise though.
The weakest link in your network is the userbase. For most users creating a strong and unique password is what the boulder was to Sisyphus. We all hate doing laundry every day, taking out the trash, or some other boring and tedious task. If there is a way to cheat those processes we will, it is human nature, why would password creation, storage, and use be any different?
I’ve always argued it’s far more effective to work with human nature and not against it. YubiKeys or many of the other hardware / Passwordless Authentication options, work well with human nature and not against it. Users simply just need to start the login process, insert the key, press the key, and you are logged in. We’ve been using physical keys for thousands of years, it’s innately human nature at this point. Trying to create, store, and use an 18-character password with uppercase letters, lower case letters, numbers, special characters, that doesn’t contain any predictable words or commonly used patterns is not remotely close to working with human nature.
Related StoriesView More
By Red Siege | March 4, 2024
By Alex Reid, Current Red Siege Intern A long-time tactic of threat actors and offensive security professionals alike, tampering with LSASS.exe in order to recover credentials remains a highly […]Learn More
By Red Siege | February 15, 2024
By: Justin Palk, Senior Security Consultant SSH is an incredibly valuable tool for penetration testing. It provides us with a secure channel for administering machines, remotely executing tools, transferring […]Learn More
By Red Siege | January 22, 2024
By: Alex Reid, Current Red Siege Intern Introduction This blog post accompanies the release of an open source tool called GraphStrike which can be found here. Those familiar with my […]Learn More