Authentication

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.

"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.

If you are looking to get an understanding of the various approaches to user authentication, how they rank up, and what libraries to use to implement it in ASP.NET Core, then check out my new Pluralsight course: “ASP.NET Authentication – The Big Picture”.

I have designed this course so that you can either watch it end to end or pick the parts that matter to you; with the aim to give you both a pragmatic overview of modern authentication, along with a practitioner’s recommendation of useful libraries with which to implement them.

Software tokens, such as those you use in software token apps such as Google Authenticator and Authy, have been getting a bit of flack recently thanks to the growing adoption of FIDO2 and WebAuthn. Software tokens (aka soft tokens) still have their benefits and are easily one of the most widely adopted second factors used alongside passwords; however, I think a lot of us are using them for the wrong reasons. Not only are soft tokens phishable, but in the event of a breach, soft tokens won’t save you.

In this article, I’m going to look how a typical TOTP software token implementation works, and then pick apart their advantages and disadvantages.