Security Frame: Authentication | Mitigations

• Consider using a standard authentication mechanism to authenticate to Web Application
• Applications must handle failed authentication scenarios securely
• Enable step up or adaptive authentication
• Ensure that administrative interfaces are appropriately locked down
• Implement forgot password functionalities securely
• Ensure that password and account policy are implemented
• Implement controls to prevent username enumeration

• When possible, use Windows Authentication for connecting to SQL Server
• When possible use Microsoft Entra authentication for Connecting to SQL Database
• When SQL authentication mode is used, ensure that account and password policy are enforced on SQL server
• Don't use SQL Authentication in contained databases

• Use per device authentication credentials using SaS tokens

• Enable Microsoft Entra multifactor authentication for Azure Administrators

• Restrict anonymous access to Service Fabric Cluster
• Ensure that Service Fabric client-to-node certificate is different from node-to-node certificate
• Use Microsoft Entra ID to authenticate clients to service fabric clusters
• Ensure that service fabric certificates are obtained from an approved Certificate Authority (CA)

• Use standard authentication scenarios supported by Identity Server
• Override the default Identity Server token cache with a scalable alternative

• Ensure that deployed application's binaries are digitally signed

• Enable authentication when connecting to MSMQ queues in WCF
• WCF-Do not set Message clientCredentialType to none
• WCF-Do not set Transport clientCredentialType to none

• Ensure that standard authentication techniques are used to secure Web APIs

• Use standard authentication scenarios supported by Microsoft Entra ID
• Override the default MSAL token cache with a distributed cache
• Ensure that TokenReplayCache is used to prevent the replay of inbound authentication tokens
• Use MSAL libraries to manage token requests from OAuth2 clients to Microsoft Entra ID (or on-premises AD)

• Authenticate devices connecting to the Field Gateway

• Ensure that devices connecting to Cloud gateway are authenticated
• Use per-device authentication credentials

• Ensure that only the required containers and blobs are given anonymous read access
• Grant limited access to objects in Azure storage using SAS or SAP

Authentication is the process where an entity proves its identity, typically through credentials, such as a user name and password. There are multiple authentication protocols available which might be considered. Some of them are listed below:

• Client certificates
• Windows based
• Forms based
• Federation - ADFS
• Federation - Microsoft Entra ID
• Federation - Identity Server

Consider using a standard authentication mechanism to identify the source process

Applications that explicitly authenticate users must handle failed authentication scenarios securely. The authentication mechanism must:

• Deny access to privileged resources when authentication fails
• Display a generic error message after failed authentication and access denied occurs

Test for:

• Protection of privileged resources after failed logins
• A generic error message is displayed on failed authentication and access denied event(s)
• Accounts are disabled after an excessive number of failed attempts

Verify the application has additional authorization (such as step up or adaptive authentication, via multifactor authentication such as sending OTP in SMS, email etc. or prompting for re-authentication) so the user is challenged before being granted access to sensitive information. This rule also applies for making critical changes to an account or action

This also means that the adaptation of authentication has to be implemented in such a manner that the application correctly enforces context-sensitive authorization so as to not allow unauthorized manipulation by means of in example, parameter tampering

The first thing is to verify that forgot password and other recovery paths send a link including a time-limited activation token rather than the password itself. Additional authentication based on soft-tokens (e.g. SMS token, native mobile applications, etc.) can be required as well before the link is sent over. Second, you shouldn't lock out the users account whilst the process of getting a new password is in progress.

This could lead to a Denial of service attack whenever an attacker decides to intentionally lock out the users with an automated attack. Third, whenever the new password request was set in progress, the message you display should be generalized in order to prevent username enumeration. Fourth, always disallow the use of old passwords and implement a strong password policy.

Password and account policy in compliance with organizational policy and best practices should be implemented.

To defend against brute-force and dictionary based guessing: Strong password policy must be implemented to ensure that users create complex password (e.g., 12 characters minimum length, alphanumeric and special characters).

Account lockout policies might be implemented in the following manner:

• Soft lock-out: This can be a good option for protecting your users against brute force attacks. For example, whenever the user enters a wrong password three times the application could lock down the account for a minute in order to slow down the process of brute forcing their password making it less profitable for the attacker to proceed. If you were to implement hard lock-out countermeasures for this example you would achieve a "DoS" by permanently locking out accounts. Alternatively, application might generate an OTP (One Time Password) and send it out-of-band (through email, sms etc.) to the user. Another approach might be to implement CAPTCHA after a threshold number of failed attempts is reached.
• Hard lock-out: This type of lockout should be applied whenever you detect a user attacking your application and counter them by means of permanently locking out their account until a response team had time to do their forensics. After this process you can decide to give the user back their account or take further legal actions against them. This type of approach prevents the attacker from further penetrating your application and infrastructure.

To defend against attacks on default and predictable accounts, verify that all keys and passwords are replaceable, and are generated or replaced after installation time.

If the application has to auto-generate passwords, ensure that the generated passwords are random and have high entropy.

The Event Hubs security model is based on a combination of Shared Access Signature (SAS) tokens and event publishers. The publisher name represents the DeviceID that receives the token. This would help associate the tokens generated with the respective devices.

All messages are tagged with originator on service side allowing detection of in-payload origin spoofing attempts. When authenticating devices, generate a per device SaS token scoped to a unique publisher.

multifactor authentication (MFA) is a method of authentication that requires more than one verification method and adds a critical second layer of security to user sign-ins and transactions. It works by requiring any two or more of the following verification methods:

• Something you know (typically a password)
• Something you have (a trusted device that isn't easily duplicated, like a phone)
• Something you are (biometrics)

Clusters should always be secured to prevent unauthorized users from connecting to your cluster, especially when it has production workloads running on it.

While creating a service fabric cluster, ensure that the security mode is set to "secure" and configure the required X.509 server certificate. Creating an "insecure" cluster will allow any anonymous user to connect to it if it exposes management endpoints to the public Internet.

Client-to-node certificate security is configured while creating the cluster either through the Azure portal, Resource Manager templates or a standalone JSON template by specifying an admin client certificate and/or a user client certificate.

The admin client and user client certificates you specify should be different than the primary and secondary certificates you specify for Node-to-node security.

Service Fabric uses X.509 server certificates for authenticating nodes and clients.

Some important things to consider while using certificates in service fabrics:

• Certificates used in clusters running production workloads should be created by using a correctly configured Windows Server certificate service or obtained from an approved Certificate Authority (CA). The CA can be an approved external CA or a properly managed internal Public Key Infrastructure (PKI)
• Never use any temporary or test certificates in production that are created with tools such as MakeCert.exe
• You can use a self-signed certificate, but should only do so for test clusters and not in production

Below are the typical interactions supported by Identity Server:

• Browsers communicate with web applications
• Web applications communicate with web APIs (sometimes on their own, sometimes on behalf of a user)
• Browser-based applications communicate with web APIs
• Native applications communicate with web APIs
• Server-based applications communicate with web APIs
• Web APIs communicate with web APIs (sometimes on their own, sometimes on behalf of a user)

IdentityServer has a simple built-in in-memory cache. While this is good for small scale native apps, it does not scale for mid tier and backend applications for the following reasons:

• These applications are accessed by many users at once. Saving all access tokens in the same store creates isolation issues and presents challenges when operating at scale: many users, each with as many tokens as the resources the app accesses on their behalf, can mean huge numbers and very expensive lookup operations
• These applications are typically deployed on distributed topologies, where multiple nodes must have access to the same cache
• Cached tokens must survive process recycles and deactivations
• For all the above reasons, while implementing web apps, it is recommended to override the default Identity Server's token cache with a scalable alternative such as Azure Cache for Redis

Authentication is the process where an entity proves its identity, typically through credentials, such as a user name and password. There are multiple authentication protocols available which might be considered. Some of them are listed below:

• Client certificates
• Windows based
• Forms based
• Federation - ADFS
• Federation - Microsoft Entra ID
• Federation - Identity Server

Links in the references section provide low-level details on how each of the authentication schemes can be implemented to secure a Web API.

Microsoft Entra ID simplifies authentication for developers by providing identity as a service, with support for industry-standard protocols such as OAuth 2.0 and OpenID Connect. Below are the five primary application scenarios supported by Microsoft Entra ID:

• Web Browser to Web Application: A user needs to sign in to a web application that is secured by Microsoft Entra ID
• Single Page Application (SPA): A user needs to sign in to a single page application that is secured by Microsoft Entra ID
• Native Application to Web API: A native application that runs on a phone, tablet, or PC needs to authenticate a user to get resources from a web API that is secured by Microsoft Entra ID
• Web Application to Web API: A web application needs to get resources from a web API secured by Microsoft Entra ID
• Daemon or Server Application to Web API: A daemon application or a server application with no web user interface needs to get resources from a web API secured by Microsoft Entra ID

Please refer to the links in the references section for low-level implementation details

The default cache that MSAL (Microsoft Authentication Library) uses is an in-memory cache, and is scalable. However there are different options available that you can use as an alternative, such as a distributed token cache. These have L1/L2 mechanisms, where L1 is in memory and L2 is the distributed cache implementation. These can be accordingly configured to limit L1 memory, encrypt or set eviction policies. Other alternatives include Redis, SQL Server or Azure Comsos DB caches. An implementation of a distributed token cache can be found in the following Tutorial: Get started with ASP.NET Core MVC.

The TokenReplayCache property allows developers to define a token replay cache, a store that can be used for saving tokens for the purpose of verifying that no token can be used more than once.

This is a measure against a common attack, the aptly called token replay attack: an attacker intercepting the token sent at sign-in might try to send it to the app again (“replay” it) for establishing a new session. E.g., In OIDC code-grant flow, after successful user authentication, a request to "/signin-oidc" endpoint of the relying party is made with "id_token", "code" and "state" parameters.

The relying party validates this request and establishes a new session. If an adversary captures this request and replays it, he/she can establish a successful session and spoof the user. The presence of the nonce in OpenID Connect can limit but not fully eliminate the circumstances in which the attack can be successfully enacted. To protect their applications, developers can provide an implementation of ITokenReplayCache and assign an instance to TokenReplayCache.

The Microsoft Authentication Library (MSAL) enables developers to acquire security tokens from the Microsoft identity platform to authenticate users and access secured web APIs. It can be used to provide secure access to Microsoft Graph, other Microsoft APIs, third-party web APIs, or your own web API. MSAL supports many different application architectures and platforms including .NET, JavaScript, Java, Python, Android, and iOS.

• Generic: Authenticate the device using Transport Layer Security (TLS) or IPSec. Infrastructure should support using pre-shared key (PSK) on those devices that cannot handle full asymmetric cryptography. Leverage Microsoft Entra ID, Oauth.
• C#: When creating a DeviceClient instance, by default, the Create method creates a DeviceClient instance that uses the AMQP protocol to communicate with IoT Hub. To use the HTTPS protocol, use the override of the Create method that enables you to specify the protocol. If you use the HTTPS protocol, you should also add the Microsoft.AspNet.WebApi.Client NuGet package to your project to include the System.Net.Http.Formatting namespace.

By default, a container and any blobs within it might be accessed only by the owner of the storage account. To give anonymous users read permissions to a container and its blobs, one can set the container permissions to allow public access. Anonymous users can read blobs within a publicly accessible container without authenticating the request.

Containers provide the following options for managing container access:

• Full public read access: Container and blob data can be read via anonymous request. Clients can enumerate blobs within the container via anonymous request, but cannot enumerate containers within the storage account.
• Public read access for blobs only: Blob data within this container can be read via anonymous request, but container data is not available. Clients cannot enumerate blobs within the container via anonymous request
• No public read access: Container and blob data can be read by the account owner only

Anonymous access is best for scenarios where certain blobs should always be available for anonymous read access. For finer-grained control, one can create a shared access signature, which enables to delegate restricted access using different permissions and over a specified time interval. Ensure that containers and blobs, which might potentially contain sensitive data, are not given anonymous access accidentally

Using a shared access signature (SAS) is a powerful way to grant limited access to objects in a storage account to other clients, without having to expose account access key. The SAS is a URI that encompasses in its query parameters all of the information necessary for authenticated access to a storage resource. To access storage resources with the SAS, the client only needs to pass in the SAS to the appropriate constructor or method.

You can use a SAS when you want to provide access to resources in your storage account to a client that can't be trusted with the account key. Your storage account keys include both a primary and secondary key, both of which grant administrative access to your account and all of the resources in it. Exposing either of your account keys opens your account to the possibility of malicious or negligent use. Shared access signatures provide a safe alternative that allows other clients to read, write, and delete data in your storage account according to the permissions you've granted, and without need for the account key.

If you have a logical set of parameters that are similar each time, using a Stored Access Policy (SAP) is a better idea. Because using a SAS derived from a Stored Access Policy gives you the ability to revoke that SAS immediately, it is the recommended best practice to always use Stored Access Policies when possible.