I have done a lot of migrations into Office 365. I started doing these migrations around about June 2011 and have been doing them almost constantly since then. One of the questions that I am asked during almost every one of those migrations is if AD FS or Password Hash Sync (PHS) is more secure. There really is not one straight forward simple answer I can give to that question, so I thought it was about time for me to write down my answer as a blog post here.

In this blog post I am going to look PHS and how it works as an authentication option for your Office 365 tenant. I will give you my best recommendation as to which you should be using under what circumstances, and why. I will try to break my overall answer down into a few small chucks as sort of a FAQ style brief. Let us get started.

The answer

If you are not feeling up to reading this whole thing, I will go ahead and put my answer right here at the top. Ready?

Use PHS. PHS is better than AD FS. PHS is also better than Pass-Through Authentication (PTA) and Text Authentication (TA).

Got it? Cool. If that is all you need, then I guess we are done here, and you can move on. Of course, most people have more questions than that, so I suppose I will keep writing.

Why in the world would I agree to give all my user’s passwords to Microsoft?

I get this question a lot. The answer I give is…

“You absolutely should not give your password to Microsoft. In no way, shape, or form is it a good idea to give your password to anyone and that includes Microsoft.”

At this point I often see a lot of confused looks. PHS is the system that syncs my passwords from my on-premises Active Directory into Azure AD, right? No, that is not correct. PHS syncs a hash of your password, not your password. That is a very important distinction that you need to understand before you can make an informed decision. Let us look at what a hash is.

How do I know if X encryption is secure?

Encryption is difficult to understand. I am going to start off my telling you I do not have a PhD in Mathematics, and as such I do not really understand encryption very well at all. The good news is I do not really need to understand the underlaying mathematics that make encryption work to know if a specific encryption algorithm is secure or not.

For encryption to be secure, it needs to be open source. That means that the underlaying mathematics in an encryption algorithm is publicly available so that those people who do have mathematics PhDs can look at them and determine if that encryption is secure. I would personally not use any encryption system that depends on non-open source encryption. BitLocker used to use proprietary encryption, but that is no longer the case.

What is a “hash”, and how is it different from encryption?

The simple answer here is that a “hash” is a specific type of encryption meant to ensure data integrity without ever exposing the data that is encrypted to the recipient. A hash is a one-way process. When you “hash” a password you get a result that cannot then be used to determine what the original password is. Hashes are generally a fixed length. The example hashes I use below are all 32 characters long. When passwords are hashed, the result is always a fixed length (maybe not 32 characters) regardless of the length of the original password.

As an example, if your password is “hello” and it is “hashed”, it may be turned into something that looks like this…

“hello” + hashing = 2ab96390c5dbe1437de54d0c6b1b1669

The key here is that hash has no mathematical relationship to the original password of “hello”. Awesome, right? Is that enough to make sure my passwords are secure? No, it is not!

Remember high school algebra? X + 1 = 2 solve for X. If you know two of three variables, then it is easy to figure out the third, right? Same thing applies to hashing.

As I said above, encryption must be open source for us to know if it is secure. So, if the hashing process is known to everyone, and we can get ahold of the result of that hashing process, then we can do a dictionary attack to figure out what your password is. That is to say, if bad guys intercept that hash above, they can just run the same hashing algorithm against common passwords until they get a result that matched the hash they intercepted, then they would know your password!

The solution Microsoft uses for this problem is to add salt. What does that look like?

“hello” + salt + hashing = 726ad07bc398392b46a52e3de8993687

Going back to our algebra this process looks like X + Y + 1 = 5. You don’t know X or Y, so you can’t just solve for X. Obviously the math involved in PHS are much more complex than my equation. Hopefully, you get the point.

Now if bad guys get a hold of your password hash, they cannot do a dictionary attack against it to “reverse engineer” your password. They would also need to know the salt value added, and Microsoft is not telling anyone what that is. In this way, they can still use totally secure encryption that has been mathematically tested by the smartest math nerds out there but make it impossible for bad guys to figure out your password from an intercepted hash.

PHS uses HMAC-SHA256 as the hashing algorithm. They take the “password” (more on this later because AAD Connect never actually sees your password at all) and add a user specific salt value and run it through that hashing algorithm to get the hash that is sent to Azure AD and stored there for authentication.

I wanted to see what this looks like, so I found THIS website. Feel free to play around and see the results you get. Below is a picture of a test I ran…

PHS doesn’t even hash your passwords

I lied above. I said AAD Connect takes your password, adds “salt”, adds “hashing”, and gets the hashed value that is sent to Azure AD. That is not completely true.

Active Directory on-premises does not store your passwords either, so AAD Connect never has access to your actual password to start its hashing process. AD itself only stores a hash of your password.

At this point, I am not going to “re-hash” (see what I did there) the hashing process that is done by AD on-premises before it stores your passwords on your domain controllers. There are two reasons for this

1. The password hashing process that AD uses on-premises is not that great.

2. The details of that hashing process is different for different for different versions of Windows Server and different AD function levels.

The point here is that some level of hashing is done on your password before AAD Connect ever sees it. My understanding is that first hashing done by on-premises Active Directory is not that great, but again I am not a mathematical genius. Here is my crud understanding of how the password hashing process goes…

“password” + weak on-prem hash = on-prem password hash (OPPH)

OPPH + salt + HMAC-SHA256 = strongly hashed password sent to Azure AD by AAD Connect

It is my understanding that strongly hashed password that is sent to Azure AD by AAD Connect can not be reversed into your original password in any time frame that would be considered useful. That is why I feel comfortable recommending PHS as secure.

But wait, there’s more

Hopefully I have convinced you that PHS is secure in the sense that it is not sending your end-user’s passwords to Microsoft. There is another reason why I recommend PHS over AD FS, and that is because of my constant companion Murphy.

You know Murphy, right? The guy from “anything that can go wrong will go wrong”.

I prefer PHS to AD FS because deploying AAD Connect and setting it to do PHS is very easy. Maybe I should say that it can be very easy to deploy AAD Connect to do PHS. It is possible to really dig into AAD Connect and make your life difficult.

AAD Connect is design by Microsoft so that it can be deployed to do PHS securely by anyone who qualifies with the most basic competency as an IT professional. That give PHS as decided advantage over AD FS for most organizations in most situations.

At this point, I can feel many of you out there are saying “I’m not an idiot. I can deploy AD FS and keep it secure. I feel more comfortable with my skills than I do trusting Microsoft to do its voodoo magic to hash my end-user’s passwords.”

The problem is that while we are capable of being smart, we are also capable of being dumb too. Everyone gets busy, everyone takes short cuts. Everyone forgets to patch. We are people and we make mistakes. Deploying the simple AAD Connect with PHS system is more secure than deploying AD FS because people are involved, and people mess up. If you want to make sure your organization is secure, it is less likely that PHS mistakes will cause a problem than AD FS mistakes.

And still, there is even more reason to use PHS

To this point I have laid out my answer to the security question as best as I can. Still there is even more reason to use PHS.

Using PHS means that Microsoft can build and maintain cool authentication features for you in the cloud, and that is what you are paying for!

Smart Lockout, IP Lockout, and Microsoft Leaked Credentials Service are additional services that are possible when you use PHS. You just do not get to take advantage of these services when you use AD FS.

Furthermore, should your tenant experience a Denial of Service (DoS) and/or Password Spray attack, Microsoft will take the brunt of that traffic when you use PHS. When authentication happens via on-premises AD FS your server is responsible for managing the load and potentially causing downtime.

Wrap up

Does that cover it? Hopefully at this point, you feel comfortable using PHS for your Azure/Office 365 tenants. There are circumstances where I would recommend AD FS (or PTA, or maybe even text authentication) over PHS but those circumstances are rare.

It is my strong opinion that PHS is the best choice for authentication to your Azure/Office 365 tenant if you are syncing identities from an on-premises Active Directory.

Questions and comments are welcome below, or on Twitter to @MCSMLab.