All Your Dev Are Belong To Us

Even though the OAuth 1.0a specification has been officially made obsolete by OAuth 2.0 , it remains in active use for legacy implementations. A recent project required me to be able to consume an OAuth 1.0a request, specifically to calculate and validate the oauth_signature parameter. This was in a .NET Core 3.0 project, which (as far as I can tell!) doesn't have any libraries that help with this specification. I really didn't feel comfortable taking a dependency hit on this one by bringing in a third-party NuGet package. Many of the options provided far more than I needed, and most were (understandably) no longer in active development or supported. Taking on an unsupported "black box" dependency with anything related to security doesn't sit quite right with me. So I rolled my own implementation for just the subset of features that I needed to support (verification only, and OAuth parameters passed as form post data). This is not meant to be a complete imple

Any application that requires user authentication must take adequate steps to protect the user accounts for which it is responsible. This includes correctly handling workflows such as proper password hashing and storage, providing feedback that doesn't disclose information useful to an attacker, providing means for password reset, etc. The ASP.NET Core Identity membership system provides much of this functionality out-of-the-box, using tried and tested implementations that avoid common mistakes and pitfalls. It is an excellent platform on which to build when developing your application's authentication system. ASP.NET Core Identity provides a means of mitigating brute force login attempts through user lockout. After a configurable number of failed login attempts, a user's account is locked for a period of time. Both the maximum number of attempts, and the lockout period, are configurable. While this is certainly a valid strategy, it does have some weaknesses: The syst

This article walks through the process of capturing and detecting a user's time zone at the point of registration. This information can then be used to display time-related information in the local zone of the user. Note that, in most cases, you should still store datetime information in UTC; the time zone is only used for local display. This setup assumes a site running Razor Pages in ASP.NET Core 2.2, although there's nothing particularly framework-specific in what follows. The same ideas should carry over quite easily to, for example, a regular ASP.NET MVC site. We start with a basic registration page: Register.cshtml @page @model RegisterModel <h1> Create an account </h1> <form method= "post" > <div asp-validation-summary= "ModelOnly" ></div> <div class= "form-group" > <label asp-for= "FirstName" ></label> <input asp-for= "FirstName"