Chat with us, powered by LiveChat

Blog

Back

How Secure is DirSync with Password Synchronisation?

11 Jun 2013 by Emma Robinson

Microsoft have recently released a new version of the Windows Azure Active Directory Sync tool, also known as DirSync.
The biggest change in this version is that it now has the ability to synchronise your on-premise Active Directory user passwords to your Azure/Office 365 cloud tenant.
Sending passwords across the internet always causes me to raise my eyebrows and it prompted me to look a little deeper into how this actually works.
The Microsoft TechNet article states the following:

When synchronizing passwords using the password sync feature, the plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services.
Additionally, there is no requirement on the on-premises Active Directory to store the password in a reversibly encrypted format. A digest of the Windows Active Directory password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer’s on-premises environment.

To investigate these statements further we installed the new version of DirSync onto our test environment and sniffed some of the traffic with a proxy server to see what was happening when a user changed their password.
The first thing we found was that the connection to Microsoft was obviously encrypted over a HTTPS connection. Most things are encrypted this way these days, so this is a good thing!

Sniffing DirSync Traffic with a Proxy

Sniffing DirSync Traffic with a Proxy


Our proxy server has the ability to decrypt this HTTPS traffic and we can look further into what is happening within this change password transaction.
We changed the passwords of a few of our test users a couple of times to determine the pattern of what was happening and found the exact part of the request that was sending the Password Hash to Office 365.

CredentialData�fv1;PPH1_MD4,d05c5f0b6126483e6570,100,3688e85a044e728a6eee571fb9ac7d21d89a477b09ac8e33e344f53d924839f7;SourceAnchor�SFh+npbKfU+xtYpaXZR77Q==

This data is broken into two parts:
SourceAnchor
It seems that this refers to the ImmutableID of the object who’s password has been synchronised. DirSync uses the ImmutableID to match up users between the on-premise Active Directory and the Office 365 Active Directory.

PS C:\Users\burns_000\Desktop> get-msoluser | Select UserPrincipalName,ImmutableID
UserPrincipalName                                           ImmutableId
-----------------                                           -----------
melissa@alantest4.onmicrosoft.com
dan@checksocial.net                                         3+hQKWCvnkGYfhaPOuePVA==
david@alantest4.onmicrosoft.com
testuser1@checksocial.net                                   SFh+npbKfU+xtYpaXZR77Q==
ben@alantest4.onmicrosoft.com
james@alantest4.onmicrosoft.com
CogmotiveReports@alantest4.onmicrosoft.com
chris@alantest4.onmicrosoft.com
alan@alantest4.onmicrosoft.com
cynthia@alantest4.onmicrosoft.com
testuser2@checksocial.net                                   bTSpcUEddECz36TbSUQQQQ==
PS C:\Users\burns_000\Desktop>

CredentialData
The CredentialData most likely refers to the hash of the users password referred to by Microsoft in the TechNet article. As Microsoft promised, it is definitely a hash of the users password and at no point is anything about the users password sent in clear text. This is also a good thing!

PPH1_MD4,d05c5f0b6126483e6570,100,3688e85a044e728a6eee571fb9ac7d21d89a477b09ac8e33e344f53d924839f7

Interestingly, the data makes reference to MD4, which is an old type of hashing algorithm and is widely considered to be insecure. I am not sure why this is mentioned here, but could refer to the MD4 based hashing used in NTLM.
Edit: A user in the comments section adds more detail about this HASH:

The hash over the wire that is captured above is not MD4 hash of clear text password. It is a secure PBKDF2 key derived from SHA256 hash of the MD4 hash (derived from crypto API documented at http://msdn.microsoft.com/en-us/library/windows/desktop/dd433795(v=vs.85).aspx) per RFC 2898.

Talented security researches are getting much better at cracking these types of password hashes, so I wouldn’t say it is impossible for someone to get a plain text password based on this hash.

So is DirSync with Password Synchronisation Secure enough for my Organisation?

Yes, I’d say so. Even if a hacker was able to decrypt the HTTPS traffic (which is unlikely), they would still have to content with the hashed password itself.
There are much easier ways for a hacker to get a users password, such as using Social Engineering or Keyloggers.

How can I best ensure the security of my DirSync setup?

Firstly, make sure that the server running DirSync is always completely patched with security updates and locked down to un-authorised access. The only reason I was able to decrypt the HTTPS traffic in the first place was because I had administrator access to the DirSync server in the first place.
Secondly, make sure that your Active Directory environment enforces complex user passwords. If an attacker somehow managed to get access to the password hashes it is much more difficult and time consuming to crack a long and complex password rather than a simple one.
Thirdly, if absolute security is a primary concern we recommend you implement Active Directory Federation Services with Two-Factor Authentication instead of DirSync with Password Synchronisation.
At the end of the day I believe that the convenience of having your users passwords synchronised between on-premise and cloud outweighs the small risk that your environment will be compromised through DirSync.

Related Posts

These other blog posts may be of interest to you:

whois: Andy White Freelance WordPress Developer London