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!

Advertisement

Where do users change their phone number for resetting O365 password?

It seems a post very straightforward, but a client fired me this question and I thought that I was pretty sure about the answer, but no, I discovered something new for me in our marvellous O365 world.

My client wanted to change their phone and mail, when they must reset their password. If you remember, the first time that you log into O365, it asks for this data to complete your “recovery” profile. So, when he asked me to change this data, I guided him to follow this procedure:

cp

  • Click on my profile

cp2

  • Update profile with your own/new info

Easy right?

If you follow this procedure to change your O365 password recovery data, you’re as much as wrong as I was. This procedure does not change your initial data, it only changes your profile information. So where do I have to access to change this data? Of course, Azure…

We know that every O365 tenant shares the Azure AD, so in Azure we also have the user information. In this case, the only thing that we have to do is to access to http://portal.azure.com go to Azure Active Directory resource, users and groups and select the user that you need to change their information.

cp5

cp3

After doing this, you will be able to reset your password with the new data that has been introduced.

Keep in mind, that you’ll need permissions in the Azure resource in order to modify this “personal” information, if you don’t have the properly permission, this information will be greyed out.

cp4.png

Hope it helps!

 

ADFS: Configure your password change

Users are always allowed or forced to change their passwords, and sometimes this actions increment the amount of work to IT. However, in ADFS 3.0 include a feature that enable a self-service portal password change available for your end-users.

So this post tries to follow the steps to configure it:

  • First, enable the Password Change Portal:Open your AD FS Management tool on the primary server, navigate to the EndPoints under Services\Endpoints. At the bottom you will see the /ADFS/portal/updatepassword/ endpoint, right click it and choose enable. Right click again and choose enable on proxy.
  • Test change password portal: browse to https://sts.domain.com/adfs/portal/updatepassword you will similar to the adfs login page where you can update your password
  • Enable password expiry notification: You can configure Active Directory Federation Services (AD FS) to send password expiry claims to the relying party trusts (applications) that are protected by ADFS. To do this it is necessary to configure a Claim Rule:

c1:[Type == “http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime”%5D => issue(store = “_PasswordExpiryStore”, types = (“http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime”, “http://schemas.microsoft.com/ws/2012/01/passwordexpirationdays”, “http://schemas.microsoft.com/ws/2012/01/passwordchangeurl”), query = “{0};”, param = c1.Value);

  • Finally: you can tweak your ADFS login page to show a link to the change password portal

That’s all!

Ref: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-to-send-password-expiry-claims

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-user-sign-in-customization