The word password-less gets thrown around a lot lately, and while everybody is talking about it, I haven’t met any enterprises that actually managed to eliminate passwords. Eliminating passwords is a big challenge, and I believe big challenges should be solved in small steps. So in this blog post, I will suggest a series of recommended steps that would help enterprises eliminate passwords. Frankly, this isn’t something I would recommend to every enterprise – it’s a lot to take on. But the first steps should be practical for everybody, and should already be enough to relieve most of the pain inflicted by passwords while strengthening the organisation’s security.
Can We Just Get Rid of Passwords?
Let’s start with a thought experiment: what would happen if you got rid of password complexity requirements in the enterprise or if you removed the requirement to change passwords often? These changes are likely to have an immediate positive impact on the happiness levels of your employees. However, right after that, you would get hacked. That’s because both user endpoints and enterprise systems will become an easy target for hackers.
So before you even begin thinking of getting rid of passwords, you need to ensure secure access to all endpoints and enterprise systems with something better than a password.
Fortunately, combining Windows Hello for Business and Silverfort, you can achieve this. I will start with an overview of WHFB and how it should be used, and continue with explaining why it’s important to add Silverfrot and how Silverfort can ensure secure access to everything on top of the endpoint.
What is Windows Hello for Business (WHFB)?
In an effort to go password-less, Microsoft introduced the ‘Windows Hello’ feature with the release of Windows 10. WHFB is a variant of this feature that is designed for corporates. The feature allows a secure way to access your device, Active Directory (AD) and Azure Active Directory (Azure AD) by leveraging the following capabilities:
WHFB places great significance on your device, as it holds the keys to AD and Azure AD. Therefore, it’s important to prevent malicious actors from unlocking the device and getting to those keys. However, I’m baffled by the choice to replace the passwords with pin-codes. Is that really enough to claim the login is now password-less? because a pin-code is not a password? Is that enough to protect the device?
Thankfully, Microsoft offers additional factors for unlocking your device, which – if combined with the pin-code – should provide better-than-password-only-security for unlocking the device.
Authentication to Active Directory (AD)
Once you unlock your computer, you unlock a private key that’s saved on your TPM, and that private key can be used for Kerberos authentication with AD. If your endpoint policies allow storing cached credentials on the computer, when you logon – the computer will unlock without authenticating to Active Directory. Otherwise, if credentials aren’t cached, your computer will have to request a Kerberos TGT, and a host ticket before it unlocks. Forcing authentication to AD will be more secure than just relying on cached credentials.
Authentication to Azure AD
Authentication to Azure AD is similar, and also relies on the private key saved on the device. It’s better to require authentication to Azure AD before unlocking the device. Below is a figure that depicts the authentication flow with WHFB in a hybrid configuration.
Is Multi-Factor Unlock the Same As Multi-Factor Authentication (MFA)?
According to the way FIPS defines MFA, a physical token that requires something you know or are to unlock is considered MFA, because one factor is the physical token (something you have), and the other factor is the gesture you provide. According to this definition, the computer can be considered a physical token and WHFB can be formally considered MFA even if multi-factor unlock is disabled. The distinction is that if the resource that you want to protect is the device itself, you need multi-factor unlock to have MFA to it. If the resource that you want to protect is external to the device, WHFB without multi-factor unlock suffices.
Of course, these are all formalities, and if you want best security you should always require multi-factor unlock.
Which deployment and trust model should I choose?
Microsoft has several deployment types to choose from.
- Hybrid Azure AD Joined Key Trust Deployment
- Hybrid Azure AD Joined Certificate Trust Deployment
- Azure AD Join Single Sign-on Deployment Guides
- On Premises Key Trust Deployment
- On Premises Certificate Trust Deployment
I don’t think many organizations can seriously consider the last 3 because most organizations aren’t ready to get rid of their AD, and are probably moving to the cloud (or will be soon).
This leaves us with the Hybrid Azure AD Joined options. I recommend going with the Certificate Trust Deployment, because in addition to local logins it also enables security for remote desktop.
What happens when users are offline?
When I first tried WHFB, I was worried about not being able to login when my computer is offline. Microsoft’s diagrams show the authentication to Azure AD as a preliminary authentication flow for unlocking the device. In reality, this usually happens before the computer unlocks, but it’s not a necessary step to unlock your computer. So users will be able to unlock their computers even when they’re offline. This also means that we can’t rely on Azure AD for preventing unauthorized access to user devices.
Improving the Security of WHFB
There are four scenarios where WHFB leverages MFA:
- Multi-factor unlock
- Initial authentication to AD
- Initial authentication to Azure AD
- Device registration
However, there’s one big unsolved issue – MFA is not required for accessing sensitive resources inside the network, after the initial login. This means that once the user is logged in, if the device has malware on it, the malware can steal the credentials (or a hash) and then it’s free to propagate throughout the network. To make things worse, Single-Sign-On (SSO) opens the door for the attacker to access all of the resources without any additional verification.
What Doesn’t WHFB Cover?
WHFB covers Azure AD and AD when the client is an updated Windows 10 device. But in many enterprise scenarios, this is not the case. Just to give a few examples:
- LDAP applications
- Applications that initiate Kerberos authentication as the client (not SSO)
- Windows 7
- Windows servers
We all have these in our environments, so you need to figure out how to protect them from unauthorized access.
How Can Silverfort Help?
Protecting Resources Within the Network
Silverfort can enforce MFA and risk-based authentication to ensure secure access to sensitive resources within the corporate network and cloud environment. It’s important to note that Silverfort secures access to resources after the user device has been unlocked.
You can use a solution like Silverfort to add Risk-Based Authentication to any of the systems that WHFB doesn’t cover. Then if you want to reduce the footprint of passwords, you can start by simplifying the password policy in the organization. If you’re adding MFA to all authentication scenarios with a password, the password doesn’t have to be as complex (you can even use a 6 digit pin-code), and it doesn’t have to be changed that often. This step already significantly reduces the cost of passwords management to the organization. The other part is gaining visibility to the
access requests to applications – Silverfort helps you identify all access requests and gradually replace their authentication with a password-less authentication mechanism.
Mobile MFA for the endpoint
If you want to implement stronger security before unlocking user workstations, you can use Silverfort’s MFA solution as an additional authentication factor. Silverfort can work with out-of-band authentication, which can provide additional security over the factor Microsoft supports.
In addition, Silverfort can add out-of-band authentication to devices that don’t support WHFB, such as Windows 7 devices.
MFA for Remote Desktop
Silverfort provides MFA for remote desktop, even if you chose to go with the Hybrid Azure AD Joined Key Trust Deployment.
MFA for device registration
The first step of registering a device to Azure AD, typically requires MFA, and that can be achieved with Silverfort.
How to Go Password-less
Microsoft recommends the following steps for going password-less:
1. Develop a password replacement offering
We all know that one factor is not enough. Therefore, removing the password poses a challenge for security, because now you need two factors other than a password. WHFB solves part of this challenge, but as mentioned earlier, it leaves other scenarios unprotected. Your password replacement has to include an alternative authentication factor that can protect all of your resources.
2. Reduce user-visible password surface area
The first step here is enabling WHFB. Then, you probably want to use a solution like Silverfort to automatically map all the resources that still use passwords.
3. Transition into a password-less deployment
That’s where it gets tricky. The applications that don’t support password-less authentication are going to make it difficult to achieve this step. As mentioned before, I recommend an intermediate step before that, which is enforcing MFA for these applications and at the same time reducing passwords’ length and complexity.
4. Eliminate passwords from the identity directory
If your entire environment is covered by SSO, and login to all endpoints is based on Windows Hello for Business, you don’t need a password in your directory at all. However, I think most organizations have a long way to go before that would be possible.
An Extended Password-less Strategy
The strategy I recommend has a couple of more steps than Microsoft’s, but I think it’s a bit more practical, and it allows you to gain value very early in the process:
image: recommended process for implementing a ‘passwordless’ strategy
Most organizations will implement the top part of the process to improve the security of the organization. It will simplify the login process for most users accessing most applications allowing them to use a simple, easy to remember password. However organizations that want to eliminate passwords completely, will need to go through the additional steps.
Whether you chose to implement a full passwordless strategy or not, I think the combination of Windows Hello for Business and a wide multi-factor authentication solution can significantly improve the user experience and the overall security posture of the organization.
Enabling WHFB and Multi-Factor Unlock isn’t difficult. Implementing an MFA solution to secure access to your most sensitive assets – can be more challenging, depending on the solution you use. If you want to know how Silverfort can help you simplify the deployment as well as enable secure authentication for any sensitive system – without requiring software agents or in-line proxies – let us know. We’d be happy to help.
Wishing you all Happy Holidays and a Wonderful and Safe 2020!