Recommended audience: IT Operations Managers, Enterprise Architects, Solution Architects

In the context of hybrid identity implementations across your on-premise and cloud environment, I’ve described extensively in this article how to make your identities available in Azure and Office 365.

Among the different options, stands the so-called Password Hash Sync (PHS), which synchronizes the password hashes from your on-premise Active Directory to Azure Active Directory. Among the common security concerns, there is one of synchronizing this information to the cloud, deeming the method insecure because your password would be safer in your on-premise environment, but is it really so? We must not trust completely every statement from the product vendors, but at the same time, we must dive into the implementation facts and analyze the benefit to risk ratio.

The password hash

The password hash sync process starts in your on-premise environment from your local Active Directory, via the Azure AD Connect server. Users’ passwords in Active Directory are not stored in plaintext, but instead, as non-reversible hash values. A hash value is a result of a monodirectional function that takes as input a string of random size (a user’s password in this case) and produces as output a string of fixed size (the hash value). This process is repeatable so that producing the hash from the same password, outputs always the same value. For increased security, an additional layer of security can be added, called salt, that adds random characters to the original input password. Two salted hashes even generated from identical input strings (identical password) won’t have the same value.

The sync process

We have established that the passwords in your on-premise environment are stored in a non-reversible hash value format. Let’s look now at the process of hash synchronization from the on-premise Domain Controllers to the cloud.

1. Every two minutes, the password hash synchronization agent on the AD Connect server requests stored password hashes (the unicodePwd attribute) from a DC. This request is via the standard MS-DRSR replication protocol used to synchronize data between DCs. The service account must have Replicate Directory Changes and Replicate Directory Changes All AD permissions (granted by default on installation) to obtain the password hashes.

2. Before sending, the DC encrypts the MD4 password hash by using a key that is an MD5 hash of the RPC session key and a salt. It then sends the result to the password hash synchronization agent over RPC. The DC also passes the salt to the synchronization agent by using the DC replication protocol, so the agent will be able to decrypt the envelope.

3. After the password hash synchronization agent has the encrypted envelope, it uses MD5CryptoServiceProvider and the salt to generate a key to decrypt the received data back to its original MD4 format. The password hash synchronization agent never has access to the clear-text password. The password hash synchronization agent’s use of MD5 is strictly for replication protocol compatibility with the DC, and it is only used on-premises between the DC and the password hash synchronization agent.

4. The password hash synchronization agent expands the 16-byte binary password hash to 64 bytes by first converting the hash to a 32-byte hexadecimal string, then converting this string back into binary with UTF-16 encoding.

5. The password hash synchronization agent adds a per-user salt, consisting of a 10-byte length salt, to the 64-byte binary to further protect the original hash.

6. The password hash synchronization agent then combines the MD4 hash plus the per-user salt and inputs it into the PBKDF2 function. 1000 iterations of the HMAC-SHA256 keyed hashing algorithm are used.

7. The password hash synchronization agent takes the resulting 32-byte hash, concatenates both the per-user salt and the number of SHA256 iterations to it (for use by Azure AD), then;

8. Transmits the string from Azure AD Connect to Azure AD over TLS.

9. When a user attempts to sign in to Azure AD and enters their password, the password is run through the same MD4+salt+PBKDF2+HMAC-SHA256 process. If the resulting hash matches the hash stored in Azure AD, the user has entered the correct password and is authenticated.

We’ve examined the sync process, let’s look now at the key takeaways and advantages of PHS.

Key takeaways

• The sync process does not send the password hash stored in Active Directory but the SHA256 hash of the original MD4 hash. This implies that the hash being synchronized cannot be used in an on-premise pass-the-hash (PtH) attack.

• The SHA256 hash that is synchronized cannot be decrypted.

• The per-user hash being sent to AAD undergoes 1’000 iterations of the HMAC-SHA256 hashing algorithm.

• Azure AD Smart Lockout and IP Lockout assists in blocking brute-force password attempts by malicious actors, while allowing legitimate users to sign in.

• PHS unlocks Azure AD Identity Protection leaked credentials feature: this is particularly relevant as it monitors public web sites and the dark web in collaboration with researchers, law enforcement and Microsoft Security teams plus other trusted sources. When the service acquires username/password pairs from malicious sites, the passwords are sent through the same HMAC-SHA256 hashing algorithm and are checked against Azure AD users’ password hashes to determine if the users’ credentials have been leaked, with the possibility of performing an auto-remediation action such as demanding MFA, a change of password, or both.

Irreversibility of the hashing proces

How much irreversible is the hashing process itself? Let’s put it into perspective to defy the security concerns of brute force attacks: even considering the power of supercomputers available today, to try all possible combinations it will take more time than the time since planet Earth exists, hence it’s not possible to solve the hashing algorithm problem using a pre-image attack in a reasonable amount of time (given some hash value H we want to obtain the password text P so that SHA-256(P) = H).

What’s next?

We described how implementing PHS could help organizations discover leaked credentials and additional intelligence that today is not available in the on-premise environment. This discovery process is particularly important because often people use the same password over and over again through different services, hence it might be important to know if this password is known already by malicious actors.

In this article, we demonstrated how PHS is a secure method to implement a hybrid identity strategy and it actually defies an additional concern whereas for example ADFS is deemed to be more secure, whilst for example, if not secured correctly, it’s exposed to brute force attacks from the Internet. This does not mean that PHS is always the to-go strategy and its implementation need to be driven and analyzed by compliance rules and whether specific Identity Protection features are important or not.

PHS can also be implemented as a backup solution for federated authentication and as a transition strategy to unlock immediate value on Identity Protection, whilst planning ahead towards a different hybrid identity implementation, including password-less implementations, which I will cover in my next article.

Why should you choose password hash sync?

In this article, I’ve talked about the decision workflow to choose a hybrid identity strategy answering the question if you still need ADFS as a federation provider or not. Among the hybrid identity implementation options, password hash sync is not a less secure one and here are the good reasons to go for it:

• Enable the Azure Identity Protection leaked credentials report

• No need to manage the integration with an existing federation provider

• Use it as a sign-in disaster recovery method for a federation provider

• Use it as a hybrid identity transition strategy to quickly enable your identities in the cloud without adding operational dependencies with existing on-premise systems

How can we help you?

At Stellium, we have supported many companies in the implementation of a hybrid identity strategy, and we can help you to analyze your current situation and migration steps to move forward with a modern and secure cloud authentication.

Would you like to get in touch about hybrid identity and security? Go ahead and set up an appointment for a consultation call.