scottbrady91.com

I’m an Umbraco MVP for 2021! 🎉

As part of the Unicore project, Rock Solid Knowledge has been helping Umbraco HQ migrate to ASP.NET Core. My contributions have been on the identity side of the project, migrating the back-office user store to use ASP.NET Core Identity, while my colleague Emma Garland worked on the member’s user store later in the year.

In recognition of my contributions, Umbraco HQ has awarded me with an Umbraco MVP title for 2021.

Recently, I have received questions asking if Proof-Key for Code Exchange (PKCE) is a replacement for OAuth client authentication and, if so, why do my articles still use a client secret for server-side applications?

Is PKCE a replacement for client authentication? The short answer is: no.

Should you still use client authentication where possible? Yes.

When using symmetric encryption, you should be favoring authenticated encryption, such as AES-GCM (Galois/Counter Mode), rather than unauthenticated encryption, such as AES-CBC (Cipher Block Chaining).

Authenticated encryption provides you with confidentiality and an additional integrity check, allowing you to defend against various attacks based on the chosen-ciphertext attack.

In this article, you’re going to see how to use the AES-GCM implementation found in System.Security.Cryptography, available as of .NET Core 3. If you’re not there yet, I’m also going to show you how to do the same with Bouncy Castle.

Password shucking is a method of stripping layers off an updated password hash, removing the benefits of its new password hashing algorithm and reverting it to its weaker algorithm. Password shucking can be used by an attacker against old rehashed passwords or pre-hash passwords, enabling them to strip away or “shuck” off the strong outer password hashing algorithm.

In this article, I’m going to walk through the theory of password shucking. I initially struggled with understanding password shucking, so this is my take in explaining it. If you prefer a different style, I recommend checking out the DEFCON talk from Sam Croley (aka Chick3nman), which is embedded at the end of this article.

Modern HTML attributes such as “passwordrules” and “autocomplete” allow you to tell password generators where your set password fields are and how they should generate passwords.

While password complexity rules are not the best approach for security, ASP.NET Core Identity does use them by default. This includes requirements for uppercase and special characters.

In this article, you will learn how you can automatically implement the “perfect” set password field using your existing ASP.NET Identity password policy and a tag helper found in “ScottBrady.IdentityModel”.

ASP.NET Core Identity & password policies

ASP.NET Core Identity comes preconfigured to require uppercase, lowercase, digits, and non-alphanumeric characters, which can conflict with some password generators or the user’s particular password generation settings. If you are enforcing password rules server-side, then it is my opinion that they should be communicated client-side before the user submits an invalid one.

"passwordrules" is a new attribute on an HTML input tag that allows you to programmatically describe your password policy to password generators. For example, that the minimum length is 20, and it requires a digit and an uppercase character.

While password complexity requirements aren’t the best defense, they are commonplace across many organizations and even enabled by default in some authentication libraries. By making password generators aware of your password policy, you can at least improve the user experience.

In this article, I’m going to show you how to use the passwordrules attribute and a few other attributes that can help make the "perfect" new password field. This includes an on-page example so that you can see if your password manager/generator of choice supports the attribute.

SAML is the protocol that no one wants to use. But if you must use it, at least you now have a modern, detailed introduction to SAML thanks to my new Pluralsight course: Getting Started with SAML.

You’ll hear the common phrase that "SAML is dead", but we have been saying this for almost a decade, and it hasn’t gone anywhere. SAML continues to be one of the most used single sign-on protocols around, especially within large enterprises and government institutions.

This course is entirely programming free and is suitable for software developers of any language or stack. That being said, if you’re looking to get started with SAML in ASP.NET Core, I highly recommend this course as your first step.

I know I said I wanted to travel less…

While this year was chaotic in many different ways, writing this review has helped me recognize the positives and put my achievements into perspective.

If you are interested in writing your own review or just privately taking stock of your year, I recommend checking out the ultimate annual review.

In the same way that OAuth is not authentication, it also does not tell us what the user is allowed to do or represent that the user can access a protected resource (an API).

Understanding what OAuth is not is just as important as knowing what it is, in order to use it effectively. In this article, I’m going to discuss how OAuth does not include user authorization and why user authorization rules should not live within your OAuth authorization server.

TL;DR: OAuth is not suitable for user authorization. The fact that you have an access token that allows you to act on the user’s behalf does not mean that the user can perform an action.

As part of my work with ScottBrady.IdentityModel, I’ve had the chance to play with XChaCha20-Poly1305. Despite sounding a bit silly and being a pain to type, XChaCha20-Poly1305 is a useful symmetric encryption algorithm that offers an alternative to the AES we know and love.

In this article, I am going to give a high-level overview of ChaCha20, Poly1305, and XChaCha20-Poly1305. This will include some code samples using a libsodium implementation in .NET, and a silly “rolling your own” implementation to help demonstrate the differences between ChaCha20-Poly1305 and XChaCha20-Poly1305.