OATH Hardware Tokens for AzureAD

As you probably have been reading in my previous posts, I’ve been talking about FIDO2 keys, and how it can be used as a secondary authentication when signing in AzureAD.

Today, I want to talk about OATH hardware Tokens, known as Time-based One Time Password Tokens as well.

As you are aware, some authentication methods can be used as the primary factor when you sign in to an application or device, such as using a FIDO2 security key or a password. Other authentication methods are only available as a secondary factor when you use Azure AD Multi-Factor Authentication or SSPR.

The following table outlines when an authentication method can be used during a sign-in event:

But, OATH TOTP is an open standard that specifies how one-time password (OTP) codes are generated. OATH TOTP can be implemented using either software or hardware to generate the codes. OATH TOTP hardware tokens typically come with a secret key, or seed, pre-programmed in the token.

In this post, I will show you how the OTP C200 token from Feitian can be configured in Azure AD and how it works.

First of all, what you have to do is to register the key in Azure AD, in order to do this, you will need the Serial Number from the Key, and the secret key provided by the manufacturer, and then you need to create a CSV file with all the information:

Once you have done this, these keys must be input into Azure AD: Multifactor authentication – Microsoft Azure

Upload the file, and activate the key in the portal, once it is have been done, it will show you a screen like the following:

If you have any error during the upload, it will be shown in the portal itself:

You must consider that you can activate a maximum of 200 OATH tokens every 5 minutes.

Also, as you probably figure out, users may have a combination or OATH Hardware tokens, Authenticator App, FiDO Keys, etc…

Be aware that users con configure their default sign in method in the security info web: My Sign-Ins | Security Info | Microsoft.com

So, once the key has been configured for the user, which is the flow to access to the account?

I have compared the Authentication flow with the Fido2 Key Flow, the difference that you can appreciate is with FiDO2 Keys is not necessary to include my password

Finally, check out the following table from Microsoft, where you can see different persona cases and which passwordless technology can be used for each one of them

IMHO, FiDO Keys are great, but thinking as an end user they have problem: the first setup: We must rely on end user about how they configure the key and associate it with azure AD (remember the previous table). FiDO keys has the advantage to be able to be used to sign in instead of using a password in the computer.

In the other hand, OAUTH keys are great, because you as an administrator, can configure the keys in the AAD Portal, and once have been activated provide them to end users, without necessity to do any other action from the end user perspective, and the most important part, are very easy to use

Thanks to Feitian for providing such amazing tokens

You should remove that basic authentication from Exchange…

Now more than ever, you should disable your legacy authentication in Exchange Online, last year Microsoft announced that they will remove that basic Authentication next October (https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-deprecation-in-exchange-online-may-2022/ba-p/3301866)

Did you know that:

  • More than 99 percent of password spray attacks use legacy authentication protocols
  • More than 97 percent of credential stuffing attacks use legacy authentication
  • Azure AD accounts in organizations that have disabled legacy authentication experience 67 percent fewer compromises than those where legacy authentication is enabled
thumbnail image 1 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							New tools to block legacy authentication in your organization

Disabling legacy authentication for users is a must-do on your identity security checklist

Why? becasue is a security gap and Microsoft took a lot of effor to promote Modern Authentication. So, you can disable now this basic Authentication in very simple steps:

If you don’t want to use this option, you can block the access to those protocols by using Conditional Access, understanding in a very simple way the impact of the policy.

What are you waiting for?

Why you should block legacy authentication

Currently, we could say that Legacy Authentication is one of the most compromising sign-in, luckily for us, older protocols have been replacing with modern authentication services, taking the advantage that MA supports MFA, while Legacy Authentication refers to all protocols that use Basic Authentication, and only requires one method of authentication.

So, it is important thar for security reasons we need to disable legacy authentication in our environments, why? Because enabling MFA isn’t effective if legacy protocols are not blocked. For example, the following options are considered legacy authentication protocols:

  • Authenticated SMTP – Used by POP and IMAP clients to send email messages.
  • Autodiscover – Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.
  • Exchange ActiveSync (EAS) – Used to connect to mailboxes in Exchange Online.
  • Exchange Online PowerShell – Used to connect to Exchange Online with remote PowerShell. If you block Basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect.
  • Exchange Web Services (EWS) – A programming interface that’s used by Outlook, Outlook for Mac, and third-party apps.
  • IMAP4 – Used by IMAP email clients.
  • MAPI over HTTP (MAPI/HTTP) – Used by Outlook 2010 and later.
  • Offline Address Book (OAB) – A copy of address list collections that are downloaded and used by Outlook.
  • Outlook Anywhere (RPC over HTTP) – Used by Outlook 2016 and earlier.
  • Outlook Service – Used by the Mail and Calendar app for Windows 10.
  • POP3 – Used by POP email clients.
  • Reporting Web Services – Used to retrieve report data in Exchange Online.
  • Other clients – Other protocols identified as utilizing legacy authentication

How can we monitor the usage of legacy authentication in Azure AD?

Thanks to Log Analytics, Insights and workbooks, we are able to monitor the use of those protocols, for instance:

And check the non-interactive sign-ins (be careful with ADConnect sync accounts):

What we can do to avoid this?

The best way to block or report legacy authentication for users is use Conditional Access policies (Does my organization need Azure AD Conditional Access? – Albandrod’s Memory (albandrodsmemory.com) & Enabling zero trust security in your environment – Albandrod’s Memory (albandrodsmemory.com)

But the best way is creating a CA policy:

My final advice

Legacy authentication must be disabled to protect our environments, but first, start small and analyse the impact in your organization.

Till next time!

PassWordless Authentication with Fido 2 Keys – Part 2

This is a second part of my blog about reviewing Fido2 Keys from Feitian (PassWordless Authentication with Fido 2 Keys – Albandrod’s Memory (albandrodsmemory.com))

In this case, I am testing out the K33 and K44 products

The initial setup of the tenant is covered in my previous post, so I will skip the details of how to do it.

To configure the K33 key you will need to download the app “BioPass FIDO2 Manager” from the Windows Store:

And connect your K33 key via USB to the laptop (otherwise won’t be possible to configure), the configure your preferred PIN, and finally configure your fingerprints. The process to the K44 is similar, but in this case, I am using and Ipad, and the app to download is “iePassManager”

Once the two keys are configured, you’re ready to setup them in AzureAD MFA (https://aka.ms/setupmfa)

K33 process

I have explained the process of how to initially configure the K33 key, but I strongly recommend to follow the steps mentioned in K33_Microsoft_Services_Guide.pdf (ftsafe.com) to pair the key with your laptop.

Once the key has been paired, the process to configure it is simple, the only thing that you must take into account is that even it is Bluetooth Key, you must configure it as an USB key (but remember, it must be paired first with the device).

Authentication with K33

K44 Registration Process

Once again, it is needed to set up the PIN for the Key, in my case, it has been done with the Ipad, but the registration process, is easy as the video shows:

The sign in process is very similar as we’ve seen before, so I do not want to cover this, but as you can observe, the registration and use of Fido2 Keys is pretty simple.

Inclusion, MFA keys and particularly, Fido2 Keys from Feitian are great!! But now, something that you must consider when implementing Fido2 keys in your environment:

There’s no way to enforce PIN policy in Azure AD: Every user can set up their own PIN to use their key. There is no centralized way to manage PINs, but Windows Hello for Business blocks simple PIN codes by default.  The bad news is, if you add the key directly to your Azure AD account, these settings are overridden ☹

Feitian offers multiple options for connecting your key, so you’re sure to find one that works for you. Among the available connections are USB-A, USB-C, NFC, Bluetooth, PIN, biometrics, and more.

Biometrics requires app installation: you need to download the manufacturers’ application that enables fingerprint scanning, which is additional software that you must consider to install

Again, I want to thanks Feitian for providing the security keys to test out the use cases

Till next time!

My two cents for 2022

Nobody can doubt that 2021 has been the year to adopt the cloud (due to COVID of course), mostly because most of us needed to work from home. We can say that business has changed and “Probably” will never go back to was it was.

Remote work will continue growing, so in 2022 we will need to protect our assets much better, and for this, here are my predictions/concerns for the next year:

  • Hacker will continue to try to breach in our systems and try to access by the weak link in supply chains. For this, we need to reduce privileges for internal and external accounts, and not forget about machine identities
  • Every business needs to reduce his own Attack Surface, to reduce the blast radius of any exposure or incident. To achieve this, tools that provide visibility into identities and activities are essential, we need to be sure of what happened and respond quickly to those incidents
  • Protect the data is your responsibility, try to plan and build security controls for your cloud migration roadmap
  • Zero Trust will continue growing, but remember to keep in touch with all the components: network, identity, permissions, configurations… The need of tools that give visibility is essential here.
  • Currently we put the focus on protecting our user identity with MFA controls, but what about machine identities? These identities and permissions are being exploited in every breach to make lateral attacks, so we will need to be aware of that during the next year.

For now, I think that it’s all, stay tuned to the blog and happy new year!

My password recommendations from the trenches

The following are recommendations and thoughts that I extracted by working with several customers, maybe you will find it obvious, but for other people could be useful. So, let’s begin:

In the identity plane, we could say that exists 2 categories:

  • Resist Common attacks
  • Contain successful attacks

I don’t want to enter of how to resist or contain attacks, because probably I covered some of these topics in other blog entries, but for me, there is another category which is: understand the human nature.

Nothing more that understand that almost every rule that we impose to the end users, result in degradation of security. Why? Because we force users to use long passwords, with special characters, and in the end, users tend to reuse passwords which makes easier to guess or crack passwords for malicious actors.

So, in the post I will resume some of my experiences as AntiPatterns and recommendations:

  • Antipattern – Requiring long passwords: excessive length passwords (more than 10 characters) can result in a behaviour predictable, users tend to choose repeating patterns (heyholetsgoheyholetsgo) that meet the character length but clearly not hard to guess. We can say that this kind of passwords are hard to guess but lead to poor behaviours to guess the password.
    • SuperPRO Tip: You can use a long password, but in this case what I recommend is something that engineers from Microsoft do. They use a very loooooooong password, they forget it, and instead of it, they use passwordless mechanisms such as Windows Hello to sign in.

My tip: Use minimum 8 length requirement but ban common passwords with Azure AD Password Protection.

  • Antipattern – Require use of multiple character sets: probably you’re not in the same line as me, but I’ve seen that this rule do more harm than good. People use patterns as substitutions such  as $ for s, @ for a, 1 for I. So keep it in mind
  • Antipattern – Password expiration: Policy expiration drive users to use very predictable password (for example, the next password can be predicted on the previous password), end users do not tend to use a new password, the tend to update the old one.

My tip for the two previous points: Azure AD Password Protection + Conditional Access based on User Identity

  • Recommendation – Ban common passwords: For me, the most important restriction is to ban the use of common password to reduce the possibility of brute force or password spray attacks

Tip: Look at my first tip 😊

  • Recommendation – Educate end Users not to use organization credentials anywhere else: Yes I know that educate users are difficult, but you have to do it, because the tend to reuse the same password across multiple sites. It is a common practice for cyber criminals to try compromised credentials across many sites.
  • Recommendation – Enforce MFA registration and enable MFA: ensure that users maintain their security information up to date, so they can respond to security challenges if needed. Doing this, I have seen that end users are more implicated concerning digital security

Enabling MFA prevents up to 99.9% of identity attacks, and if we use other controls such as user location, the better.

PRO TIP: Use Conditional access with FIDO2 security key (PassWordless Authentication with Fido 2 Keys – Albandrod’s Memory (albandrodsmemory.com))

EndUser TIP: Consider turning on two-step verification everywhere you can

  • Recommendation – Enable risk-based Authentication: when the system detects suspicious activity, it challenges the user to ensure that they are the legitimate account owner. Personally, I think that this feature is great, but the only drawback that it is only included with AAD P2

Probably you will have different ones based on your experience but these are my recommendations. Till next time and stay safe!