Security Frame: Authentication | Mitigations

Product/Service	Article
Web Application	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
Database	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
Azure Event Hub	Use per device authentication credentials using SaS tokens
Azure Trust Boundary	Enable Microsoft Entra multifactor authentication for Azure Administrators
Service Fabric Trust Boundary	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)
Identity Server	Use standard authentication scenarios supported by Identity Server Override the default Identity Server token cache with a scalable alternative
Machine Trust Boundary	Ensure that deployed application's binaries are digitally signed
WCF	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
Web API	Ensure that standard authentication techniques are used to secure Web APIs
Microsoft Entra ID	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)
IoT Field Gateway	Authenticate devices connecting to the Field Gateway
IoT Cloud Gateway	Ensure that devices connecting to Cloud gateway are authenticated Use per-device authentication credentials
Azure Storage	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

Consider using a standard authentication mechanism to authenticate to Web Application

Title	Details
Component	Web Application
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	N/A
Details	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 must handle failed authentication scenarios securely

Title	Details
Component	Web Application
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	N/A
Details	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

Enable step up or adaptive authentication

Title	Details
Component	Web Application
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	N/A
Details	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

Ensure that administrative interfaces are appropriately locked down

Title	Details
Component	Web Application
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	N/A
Details	The first solution is to grant access only from a certain source IP range to the administrative interface. If that solution wouldn't be possible then it's always recommended to enforce a step-up or adaptive authentication for logging in into the administrative interface

Implement forgot password functionalities securely

Title	Details
Component	Web Application
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	N/A
Details	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.

Ensure that password and account policy are implemented

Title	Details
Component	Web Application
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	N/A
Details	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.

Implement controls to prevent username enumeration

Title	Details
Component	Web Application
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	N/A
Steps	All error messages should be generalized in order to prevent username enumeration. Also sometimes you can't avoid information leaking in functionalities such as a registration page. Here you need to use rate-limiting methods like CAPTCHA to prevent an automated attack by an attacker.

When possible, use Windows Authentication for connecting to SQL Server

Title	Details
Component	Database
SDL Phase	Build
Applicable Technologies	On-premises
Attributes	SQL Version - All
References	SQL Server - Choose an Authentication Mode
Steps	Windows Authentication uses Kerberos security protocol, provides password policy enforcement with regard to complexity validation for strong passwords, provides support for account lockout, and supports password expiration.

When possible use Microsoft Entra authentication for Connecting to SQL Database

Title	Details
Component	Database
SDL Phase	Build
Applicable Technologies	SQL Azure
Attributes	SQL Version - V12
References	Connecting to SQL Database By Using Microsoft Entra authentication
Steps	Minimum version: Azure SQL Database V12 required to allow Azure SQL Database to use Microsoft Entra authentication against the Microsoft Directory

When SQL authentication mode is used, ensure that account and password policy are enforced on SQL server

Title	Details
Component	Database
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	SQL Server password policy
Steps	When using SQL Server Authentication, logins are created in SQL Server that aren't based on Windows user accounts. Both the user name and the password are created by using SQL Server and stored in SQL Server. SQL Server can use Windows password policy mechanisms. It can apply the same complexity and expiration policies used in Windows to passwords used inside SQL Server.

Do not use SQL Authentication in contained databases

Title	Details
Component	Database
SDL Phase	Build
Applicable Technologies	On-premises, SQL Azure
Attributes	SQL Version - MSSQL2012, SQL Version - V12
References	Security Best Practices with Contained Databases
Steps	The absence of an enforced password policy might increase the likelihood of a weak credential being established in a contained database. Leverage Windows Authentication.

Use per device authentication credentials using SaS tokens

Title	Details
Component	Azure Event Hubs
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	Event Hubs authentication and security model overview
Steps	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.

Enable Microsoft Entra multifactor authentication for Azure Administrators

Title	Details
Component	Azure Trust Boundary
SDL Phase	Deployment
Applicable Technologies	Generic
Attributes	N/A
References	What is Microsoft Entra multifactor authentication?
Steps	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)

Restrict anonymous access to Service Fabric Cluster

Title	Details
Component	Service Fabric Trust Boundary
SDL Phase	Deployment
Applicable Technologies	Generic
Attributes	Environment - Azure
References	Service Fabric cluster security scenarios
Steps	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.

Ensure that Service Fabric client-to-node certificate is different from node-to-node certificate

Title	Details
Component	Service Fabric Trust Boundary
SDL Phase	Deployment
Applicable Technologies	Generic
Attributes	Environment - Azure, Environment - Stand alone
References	Service Fabric Client-to-node certificate security, Connect to a secure cluster using client certificate
Steps	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.

Use Microsoft Entra ID to authenticate clients to service fabric clusters

Title	Details
Component	Service Fabric Trust Boundary
SDL Phase	Deployment
Applicable Technologies	Generic
Attributes	Environment - Azure
References	Cluster security scenarios - Security Recommendations
Steps	Clusters running on Azure can also secure access to the management endpoints using Microsoft Entra ID, apart from client certificates. For Azure clusters, it is recommended that you use Microsoft Entra security to authenticate clients and certificates for node-to-node security.

Ensure that service fabric certificates are obtained from an approved Certificate Authority (CA)

Title	Details
Component	Service Fabric Trust Boundary
SDL Phase	Deployment
Applicable Technologies	Generic
Attributes	Environment - Azure
References	X.509 certificates and Service Fabric
Steps	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

Use standard authentication scenarios supported by Identity Server

Title	Details
Component	Identity Server
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	IdentityServer3 - The Big Picture
Steps	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)

Override the default Identity Server token cache with a scalable alternative

Title	Details
Component	Identity Server
SDL Phase	Deployment
Applicable Technologies	Generic
Attributes	N/A
References	Identity Server Deployment - Caching
Steps	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

Ensure that deployed application's binaries are digitally signed

Title	Details
Component	Machine Trust Boundary
SDL Phase	Deployment
Applicable Technologies	Generic
Attributes	N/A
References	N/A
Steps	Ensure that deployed application's binaries are digitally signed so that the integrity of the binaries can be verified

Enable authentication when connecting to MSMQ queues in WCF

Title	Details
Component	WCF
SDL Phase	Build
Applicable Technologies	Generic, NET Framework 3
Attributes	N/A
References	MSDN
Steps	Program fails to enable authentication when connecting to MSMQ queues, an attacker can anonymously submit messages to the queue for processing. If authentication is not used to connect to an MSMQ queue used to deliver a message to another program, an attacker could submit an anonymous message that is malicious.

Example

The <netMsmqBinding/> element of the WCF configuration file below instructs WCF to disable authentication when connecting to an MSMQ queue for message delivery.

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

Configure MSMQ to require Windows Domain or Certificate authentication at all times for any incoming or outgoing messages.

Example

The <netMsmqBinding/> element of the WCF configuration file below instructs WCF to enable certificate authentication when connecting to an MSMQ queue. The client is authenticated using X.509 certificates. The client certificate must be present in the certificate store of the server.

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

WCF-Do not set Message clientCredentialType to none

Title	Details
Component	WCF
SDL Phase	Build
Applicable Technologies	.NET Framework 3
Attributes	Client Credential Type - None
References	MSDN, Fortify
Steps	The absence of authentication means everyone is able to access this service. A service that does not authenticate its clients allows access to all users. Configure the application to authenticate against client credentials. This can be done by setting the message clientCredentialType to Windows or Certificate.

Example

<message clientCredentialType=""Certificate""/>

WCF-Do not set Transport clientCredentialType to none

Title	Details
Component	WCF
SDL Phase	Build
Applicable Technologies	Generic, .NET Framework 3
Attributes	Client Credential Type - None
References	MSDN, Fortify
Steps	The absence of authentication means everyone is able to access this service. A service that does not authenticate its clients allows all users to access its functionality. Configure the application to authenticate against client credentials. This can be done by setting the transport clientCredentialType to Windows or Certificate.

Example

<transport clientCredentialType=""Certificate""/>

Ensure that standard authentication techniques are used to secure Web APIs

Title	Details
Component	Web API
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	Authentication and Authorization in ASP.NET Web API, External Authentication Services with ASP.NET Web API (C#)
Steps	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.

Use standard authentication scenarios supported by Microsoft Entra ID

Title	Details
Component	Microsoft Entra ID
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	Authentication Scenarios for Microsoft Entra ID, Microsoft Entra code Samples, Microsoft Entra developer's guide
Steps	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

Override the default MSAL token cache with a distributed cache

Title	Details
Component	Microsoft Entra ID
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	Token cache serialization in MSAL.NET
Steps	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.

Ensure that TokenReplayCache is used to prevent the replay of MSAL authentication tokens

Title	Details
Component	Microsoft Entra ID
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	Modern Authentication with Microsoft Entra ID for Web Applications
Steps	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.

Example

// ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

Example

Here is a sample implementation of the ITokenReplayCache interface. (Please customize and implement your project-specific caching framework)

public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

The implemented cache has to be referenced in OIDC options via the "TokenValidationParameters" property as follows.

OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

Please note that to test the effectiveness of this configuration, sign in into your local OIDC-protected application and capture the request to "/signin-oidc" endpoint in fiddler. When the protection is not in place, replaying this request in fiddler will set a new session cookie. When the request is replayed after the TokenReplayCache protection is added, the application will throw an exception as follows: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

Use MSAL libraries to manage token requests from OAuth2 clients to Microsoft Entra ID (or on-premises AD)

Title	Details
Component	Microsoft Entra ID
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	MSAL
Steps	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.

MSAL gives you many ways to get tokens, with a consistent API for many platforms. There is no need to directly use the OAuth libraries or code against the protocol in your application, and can acquire tokens on behalf of a user or application (when applicable to the platform).

MSAL also maintains a token cache and refreshes tokens for you when they're close to expiring. MSAL can also help you specify which audience you want your application to sign in, and help you set up your application from configuration files, and troubleshoot your app.

Authenticate devices connecting to the Field Gateway

Title	Details
Component	IoT Field Gateway
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	N/A
Steps	Ensure that each device is authenticated by the Field Gateway before accepting data from them and before facilitating upstream communications with the Cloud Gateway. Also, ensure that devices connect with a per device credential so that individual devices can be uniquely identified.

Ensure that devices connecting to Cloud gateway are authenticated

Title	Details
Component	IoT Cloud Gateway
SDL Phase	Build
Applicable Technologies	Generic, C#, Node.JS,
Attributes	N/A, Gateway choice - Azure IoT Hub
References	N/A, Azure IoT hub with .NET, Getting Started with IoT hub and Node JS, Securing IoT with SAS and certificates, Git repository
Steps	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.

Example

static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

Example

Node.JS: Authentication

Symmetric key

• Create an IoT hub on Azure
• Create an entry in the device identity registry

  var device = new iothub.Device(null);
  device.deviceId = <DeviceId >
  registry.create(device, function(err, deviceInfo, res) {})
  

• Create a simulated device

  var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
  var Message = require('azure-iot-device').Message;
  var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
  var client = clientFromConnectionString(connectionString);
  

  SAS Token

• Gets internally generated when using symmetric key but we can generate and use it explicitly as well
• Define a protocol : var Http = require('azure-iot-device-http').Http;
• Create a sas token :

  resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
  var deviceName = "<deviceName >";
  var expires = (Date.now() / 1000) + expiresInMins * 60;
  var toSign = resourceUri + '\n' + expires;
  // using crypto
  var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
  const hmac = crypto.createHmac('sha256', decodedPassword);
  hmac.update(toSign);
  var base64signature = hmac.digest('base64');
  var base64UriEncoded = encodeURIComponent(base64signature);
  // construct authorization string
  var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
  + base64UriEncoded + "&se=" + expires;
  if (policyName) token += "&skn="+policyName;
  return token;
  

• Connect using sas token:

  Client.fromSharedAccessSignature(sas, Http);
  

  Certificates

• Generate a self signed X509 certificate using any tool such as OpenSSL to generate a .cert and .key files to store the certificate and the key respectively
• Provision a device that accepts secured connection using certificates.

  var connectionString = '<connectionString>';
  var registry = iothub.Registry.fromConnectionString(connectionString);
  var deviceJSON = {deviceId:"<deviceId>",
  authentication: {
      x509Thumbprint: {
      primaryThumbprint: "<PrimaryThumbprint>",
      secondaryThumbprint: "<SecondaryThumbprint>"
      }
  }}
  var device = deviceJSON;
  registry.create(device, function (err) {});
  

• Connect a device using a certificate

  var Protocol = require('azure-iot-device-http').Http;
  var Client = require('azure-iot-device').Client;
  var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true';
  var client = Client.fromConnectionString(connectionString, Protocol);
  var options = {
      key: fs.readFileSync('./key.pem', 'utf8'),
      cert: fs.readFileSync('./server.crt', 'utf8')
  };
  // Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
  client.setOptions(options);
  //call fn to execute after the connection is set up
  client.open(fn);
  

Use per-device authentication credentials

Title	Details
Component	IoT Cloud Gateway
SDL Phase	Build
Applicable Technologies	Generic
Attributes	Gateway choice - Azure IoT Hub
References	Azure IoT Hub Security Tokens
Steps	Use per device authentication credentials using SaS tokens based on Device key or Client Certificate, instead of IoT Hub-level shared access policies. This prevents the reuse of authentication tokens of one device or field gateway by another

Ensure that only the required containers and blobs are given anonymous read access

Title	Details
Component	Azure Storage
SDL Phase	Build
Applicable Technologies	Generic
Attributes	StorageType - Blob
References	Manage anonymous read access to containers and blobs, Shared Access Signatures, Part 1: Understanding the SAS model
Steps	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

Grant limited access to objects in Azure storage using SAS or SAP

Title	Details
Component	Azure Storage
SDL Phase	Build
Applicable Technologies	Generic
Attributes	N/A
References	Shared Access Signatures, Part 1: Understanding the SAS model, Shared Access Signatures, Part 2: Create and use a SAS with Blob storage, How to delegate access to objects in your account using Shared Access Signatures and Stored Access Policies
Steps	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.