August 21, 2018

If you haven’t heard we’re lighting up Token Binding on all our important services. Azure AD is one of the first to take advantage of this. Check out what Alex and Pamela have to say on the topic. One of the most important of these improvements is the Token Binding family of specifications which is now well on its way towards final ratification at the Internet Engineering Task Force (IETF). (If you want to learn more about token binding, watch this great presentation by Brian Campbell.) At Microsoft, we believe that the Token Binding can greatly improve the security of…

Estimated reading time: 12 minutes

October 15, 2017

If you’ve ever had an experience with Credential Providers in the past, you may think the title of this post is insane — it’s not. I recently came across an interesting Github project that showed it was theoretically possible. I wanted to see if I could replicate the results myself without digging too deeply into how they did it. As it happens, I could. I created a sample project that outlines how you can do it on Github: CredProvider.NET Historically, Credential Providers have been complex components to write because they’re COM-based, and because they have weird restrictions you have to…

Estimated reading time: 5 minutes

August 21, 2017

There’s a common problem that many applications run in to when executing cryptographic operations, and that’s the fact that the keys they use tend to exist within the application itself. This is problematic because there’s no protection of the keys — the keys are recoverable if you get a dump of the application memory, or you’re able to execute arbitrary code within the application. The solution to this problem is relatively straightforward — keep the keys out of the application. In order for that to be effective you need to also move the crypto operations out of the application too….

Estimated reading time: 11 minutes

July 9, 2017

It’s been a few months since there’s been any public activity on the project but I’ve quietly been working on cleaning it up and there’s even been a PR from the community (thanks ZhongZhaofeng!). Part of that clean up process has been adding support for AES 128/256 tokens. At first glance you might think it’s fairly trivial to do — just run the encrypted data through an AES transform and you’re good to go — but let me tell you: it’s not that simple. On Securing Shared Secrets There’s primarily one big difference between how RC4 and AES are used in…

Estimated reading time: 7 minutes

March 19, 2017

In my last post I talked about how Azure AD does Kerberos Single Sign-On. Conceptually it’s a simple process, but when you dig into the details of the implementation, there are some serious hurdles to overcome. The Active Directory side of things is straightforward — it’s just a matter of manually creating an SPN and keeping the secret in sync. It gets really complicated on the Azure AD side of things though. Consider the history of web-based Kerberos. IIS has supported this for decades by way of an ISAPI HTTP module that parses out the header and hands it off to the…

If you haven’t heard we’re lighting up Token Binding on all our important services. Azure AD is one of the first to take advantage of this. Check out what Alex and Pamela have to say on the topic. One of the most important of these improvements is the Token Binding family of specifications which is now well on its way towards final ratification at the Internet Engineering Task Force (IETF). (If you want to learn more about token binding, watch this great presentation by Brian Campbell.) At Microsoft, we believe that the Token Binding can greatly improve the security of…

If you’ve ever had an experience with Credential Providers in the past, you may think the title of this post is insane — it’s not. I recently came across an interesting Github project that showed it was theoretically possible. I wanted to see if I could replicate the results myself without digging too deeply into how they did it. As it happens, I could. I created a sample project that outlines how you can do it on Github: CredProvider.NET Historically, Credential Providers have been complex components to write because they’re COM-based, and because they have weird restrictions you have to…

Recently I created the Enclave.NET project, and it shipped with a simple in-memory storage service. It’s not particularly useful in it’s current form, so I created a sample a couple weeks ago that used Azure Key Vault as the storage and crypto service. But Why? Of course, you might be wondering why you’d want to use Enclave.NET this way, since Key Vault already provides isolation given that it’s hosted far away from your service. The obvious answer is that maybe you wouldn’t use it this way — it IS isolated enough. That said, this does provide you with some extra…

Recently I came across an interesting parameter of the New-SelfSignedCertificate PowerShell cmdlet — the -Signer parameter. This parameter allows you to provide a reference to an already-existing certificate that can be used to sign the newly-created certificate. This turns out to be an extremely useful little feature because sometimes you just need chained certificates to test stuff (so much so that I wrote a library that does this for me). Not surprisingly, this cmdlet is much easier to use. $ca = New-SelfSignedCertificate -DnsName “My Certificate Authority” -CertStoreLocation “cert:\LocalMachine\My” New-SelfSignedCertificate -DnsName “child.domain.com” -CertStoreLocation “cert:\LocalMachine\My” -signer $ca And voilà.

There’s a common problem that many applications run in to when executing cryptographic operations, and that’s the fact that the keys they use tend to exist within the application itself. This is problematic because there’s no protection of the keys — the keys are recoverable if you get a dump of the application memory, or you’re able to execute arbitrary code within the application. The solution to this problem is relatively straightforward — keep the keys out of the application. In order for that to be effective you need to also move the crypto operations out of the application too….

Earlier we looked at how to build and package and then deploy nuget packages. One thing (of many) I glossed over was that whole version thing. It turns out versioning is really difficult to do. It’s kind of like naming things. There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. — Leon Bambrick (@secretGeek) January 1, 2010 I’m not going to go into the virtues of one method (like semantic versioning) over others, but really just going to show how I set it up so my silly little project always has an incrementing version…

Earlier we looked at the automated building and packaging of Kerberos.NET using VS Online. At this point the only thing we get out of it in this state is knowing the code compiles and any tests pass — which I suppose is actually quite a feat on it’s own considering I had no indicator of either when I started. We can, of course, do better! The last piece we need is automated publishing of the final nuget package to the feed for others to consume. As it turns out this is relatively straightforward to do. The process is: Defining artifacts…

The next logical step for the Kerberos.NET project is setting up automated builds and releases. What exactly does this entail? Basically, I want a build to kick off any time changes are committed to the main repo, and automatically generate a production-ready Nuget package that is available to upload if deemed worthy of release. If you’ve done any sort of build automation or release management before, you’ve got a pretty good idea of how to make this work. For a given build service do the following: Observe changes to repo Pull down changes Build project(s) Package the packages Artifact the…