Rules to Better Security

Do you know the best free .NET security videos? Watch them on SSW TV .
Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!
Rules to Better Security
  1. Do you disable insecure protocols?

    ​For better security all our servers in our environment especially those that are public facing should have certain Security protocols and Cipers disabled.

    ​​​Using a tool called "IIS Crypto 2.0" by Nartac, these protocols can be easily disabled instead of having to manually edit the Registry Keys,.

    1. Download IIS Crypto 2.0

    2. Run this on the server you wish to lock down

    3. Select the best practices button

    IIS Crypto 2.0.png

    4. Ensure that TLS 1.0 is also disabled and hit apply

    5. The server will need to be rebooted before the settings take affect

  2. Do you choose the best method of authentication for your situation?

    ​​​Authentication and authorization are complicated, and it is risky to try and implement them yourself. ​Use this rule as a guide on choosing the right service or framework for your situation.​​​


    ​​Choosing the right authentication and authorization approach for your situation can be tricky. It is a multi-faceted problem with many variables, and what seems like the right choice in one situation may not be in the other.

    Start with the Questions​​

    1. Scope - Is it an enterprise application for internal users or a consumer application for external use?
    2. Social - Do you need to support OAuth2 or OIDC?
    3. MFA - Do you need to support MFA?
    4. Scope - Do you need to share the identity across multiple applications?
    5. Volume - Do you have an estimate for how many users you need to support?​
    6. Complexity - do you need custom logic to run as part of your authentication process?

    Without the answers to these questions, it will be difficult to choose the right option. With the answers to these questions, you can use the flow charts below to help you choose the right solution.

    Your situation is unique, and every application's requirements are different. These flow charts are intended to point you towards what you should consider for your solution.

    External Applications

    External applications are B2B or B2C applications that are intended for consumption outside of your organization. 

    Flow Chart - External.png
    Figure: WebAPI (Public facing/consumer Application) - Authentication selection flow chart

    Example Template to Customer​:

    Scope - You are building a consumer facing service that will have multiple clients, including a SPA​ and a mobile app.
    Social - You want to allow your users to sign up with their social identities (Google, Facebook, Twitter, etc.) but want to allow them to create an account with you if they don't have a social login or don't want to use it.
    All users will have the same level of access once logged in.
    Volume - You anticipate 20,000 active users.
    MFA - You would like to allow users to enable MFA.

    Your choices:
    Option A (Recommended) - Azure AD B2C - B2C provides all of the functionality you need and is free for up to 50,000 monthly users.
    Option B - Auth0 - Auth0 will meet most of these requirements, however, your volume of users will exceed the free tier and you don't need the additional functionality of the paid tier.
    Option C - Identity Server - This would work but adds additional management overhead and complexity. You would also need to manage scaling to cope with your volume of users.

    Good Example: The chosen solution meets the requirements and is highlighted as per Do you manage up?​

    Internal Applications

    For internal applications, the below flow chart is intended to assist your decision by guiding you to which option or options to consider for your application. It is possible (and in some cases necessary) to use combinations of these.

    Flow Chart - Internal.png
    Figure: WebAPI (Internal Enterprise Application) - Authentication selection flow chart

    Example Template to Customer:

    Scope - You have an internal enterprise application, which will support approximately 1,000 users.
    You already have Active Directory in place and are syncing with an Azure AD tenant.
    Your users will need to access this application from anywhere.
    MFA - As per your company security policy, you must enforce MFA.

    Your choices:
    Option A (Recommended) - ​Azure Active Directory - most of the infrastructure for this is already in place for you, and it already meets all your requirements. We would just need to wire up your application to it.
    Option B - Active Directory - while your users are already in AD, it doesn't give you MFA or access outside your network.
    Option C - Okta - this is an expensive option which for this scenario, doesn't provide any advantages over Azure AD.

    Good Example: The chosen solution meets the requirements without adding unnecessary additional costs
    Note #1: All of the following options assume you are building an ASP.NET Core application, although the commercial options listed here provide libraries for most development languages, frameworks, and platforms.

    Note #2: The information here is relevant as provided, but consider other factors that may impact your decision too. For example, cost may be a factor and saving money may be more important than the added benefits of higher-cost options. Additionally, your situation may not fit neatly into one of the scenarios we have listed and may span multiple scenarios, in which case you may need to pick the option which caters to the broadest set of requirements (avoid 'mix and match').

    ASP.NET Core Identity (simple and free)

    ASP.NET Core has some built-in identity functionality that allows you to create users and roles, and manage the security of your web applications. It is extremely capable and can be used to support a broad number of scenarios. However, it is intended for use in simple web applications, and while it can be extended to support other clients, you will need to build and wire up a lot of the UI for these scenarios yourself. Your identity store will be limited to this one application, so your users will not be able to share this identity across multiple applications.

    • Free
    • Easy to set up and use
    • Supports OAuth2/OIDC providers

    • It is recommended by Microsoft that for advanced requirements you don't use this on its own - so need to add one of the below
    • Does not scale well across multiple applications - so need to add one of the below
    • For anything other than an ASP.NET Core Web app (e.g. Angular, React, or mobile), you have to build all UI yourself, such as: sign up, log, password reset, etc.

    Use this option if... 

    • You need to add identity to a simple ASP.NETapplication​​

    ​Identity Server (full control)

    Identity Server is an open-source solution that is built on top of ASP.NET Core Identity. It has extensive support for a number of authentication and authorization scenarios and supports multiple identity providers (OAuth2/OIDC) out of the box. Identity Server extends ASP.NET Core Identity to natively support multiple client types and can be used as a single identity across multiple applications.

    Identity Server is a powerful authentication solution and its core strengths are its ability to inject complex, custom logic into your authentication flow and integrate with legacy systems. If you have either of these requirements, it's likely IdenityServer will form an essential part of your solution.

    • Inexpensive
    • Allows you to define custom authentication logic
    • Supports multiple applications/identity consumers
    • Supports multiple clients and client types
    • Supports OAuth/OIDC
    • Steep learning curve
    • Requires additional setup​
    • Requires additional skillset​
    • Requires additional management

    Use this option if...

    • You need to inject custom logic into your authentication flow, or:
    • You expect to support multiple clients (e.g. web, mobile, etc), and/or:
    • ​You expect to support multiple applications

    Active Directory (for Internal Enterprise Applications)

    ​Active Directory has been the de facto enterprise identity store for most of the world for decades. Many organizations already have AD as it provides a lot of additional capability and is integrated with most of their existing enterprise applications. AD supports multiple authentication protocols, including: 

    • LDAP/LDAPS: simple to use but old tech, requires multiple queries to check permissions, roles not natively supported, and need to be managed by groups.
    • Kerberos: Excellent experience for users as it provides a silent and transparent login. But can only be used for on-premises, domain-joined computers.
    • ADFS/SAML: Modern application authentication against AD is done via ADFS with SAML. This is often extended through third-party tools such as Okta to support applications that use JWT and claims.
    • Proprietary Microsoft: Basic, NTLM, etc.​
    • ​​Already in place in most enterprise organizations
    • Users do not require an additional identity
    • Can make the application compliant with the organization's existing security policies​
    • ​​Not suited to external use
    • Can require a lot of setups to work well with company RBAC (e.g. AD groups for authorization)
    • Not natively supported off-premises​
    • No MFA included
    Use this option if...
    • Your application, domain controllers, and clients are all on the same network, and:
    • You already have AD in place and have a security policy that states that all your users must authenticate against your centralized corporate identity, and/or:
    • You want to enable pass-through/silent authentication for your users​

    Azure AD (for Internal Enterprise Applications)

    Azure AD is Microsoft's cloud-based version of its traditional on-premises enterprise identity store - Active Directory. Azure AD is different in that it is fundamentally identity only (it doesn't provide endpoint and user management features such as Group Policy) and as such provides strong identity features not natively supported by AD, such as MFA and self-service password recovery. Being cloud-based, it can authenticate users anywhere in the world (rather than just on-premises on corporate computers).​

    • ​​​Many organizations already have AAD
    • Extends existing enterprise identity to the cloud (i.e. is supported off-premises)
    • Can be used to ensure compliance with existing company security policies
    • MFA support included​

    • ​Not suited for external or consumer-facing uses
    Use this option if...

    • You want to support internal/enterprise users, and:
    • You already have Azure AD set up, and/or:
    • Your users require access from off-site, and/or:
    • You need to enforce MFA​

    Azure B2C (simple Auth as a Service)

    AAD B2C sits on top of Azure AD and includes all the benefits it provides, as well as enabling consumer-friendly features. These include integration with OAuth2/OIDC provider and more flexible/customizable login flows. B2C is well-tailored to support authentication, and while it can be extended to support additional capabilities, this requires custom development.​

    • Inexpensive and generous free tier
    • Native support for multiple OAuth2/OIDC providers
    • MFA support included
    • Relatively straightforward to setup
    • Ongoing security maintained by Microsoft
    • ​​Very limited flexibility
    • Can support roles and other extended functionality, but requires significant development​
    Use this option if...
    • You want to support MFA, and/or:
    • Your users are external/consumers, and:
    • You anticipate a high volume of users, and/or:
    • You only require basic authentication and limited or no authorization

    Auth0 (sophisticated Auth as a Service)

    Auth0 is a commercial identity product aimed at developers. It is cloud-hosted and offers out-of-the-box functionality for user signup and login, self-service password recovery, OAuth2/OIDC integration, and other consumer and user-friendly features. MFA is supported out of the box, and significant sophisticated functionality is available on the paid tiers.​


    • Good free tier
    • Very easy to set up and use
    • MFA support included
    • Supports multiple OAuth2/OIDC providers
    • Significant extensibility​
    • ​Free tier is more limited in volume than competition (B2C)
    • Free tier only includes the basic functionality (same as B2C)
    • Free tier only supports 2 social identity providers​
    Use this option if...
    • You want to enforce MFA, and/or:
    • Your users are external/consumers, and/or:
    • You require authorization or complex authentication

    Okta (for Commercial Enterprise Applications $)

    Okta is a commercial identity product aimed at enterprises. Many enterprise-centric software products, for example, Salesforce, have Okta connectors. Okta is intended to bridge the gap between enterprise authentication (such as AD) and modern software and SaaS products.​

    • ​Integrates with anything
    • Very well supported in the enterprise
    • Can simplify integration with AD​
    • ​Expensive
    • No free tier
    • Not suited to consumer-facing scenarios​
    Use this option if...
    • Your application is for internal/enterprise users, and:
    • You already have Okta in place, and/or:
    • Your application is a product that you intend to commercialize (Okta is prevalent in the enterprise and having an Okta connector is a good selling point)​

    Roll your own - a solution looking for a problem :-) 

    It is entirely possible to create a users table and a roles table in your database and create and manage users yourself.

    • Developers feel like they're ninjas for a little while
    • Can be a quick and dirty solution to the absolute most basic situation

    You have to reinvent the wheel:

    • Identity
    • Roles
    • Email verification
    • Login/Signup/Password reset
    • Claims management
    • Significant risk
    • High maintenance overhead
    • Masses of technical debt

    Use this option if...
    • You want a side project to learn more about how you might roll your own, but of course, you know never intend to put it into production :-)​
  3. Do you stay safe against the OWASP Top 10?

    The Open Web Application Security Project (OWASP) is a non-profit charity organization whose sole purpose is to enable other organizations to develop applications that can be trusted.  Their most prominent piece of literature is the OWASP Top 10​ – a list of the most critical risks found in software.  It is a “living” list, which means it is updated as vulnerabilities become known and more or less common.

    OWASP Top 10 2013

    The current OWASP Top 10 states the following are the top risks for web applications today. Knowing and securing against these will give the biggest bang-for-buck in securing your website.

    • Injection: Being able to execute arbitrary SQL, LDAP or other code via your application
    • Broken authentication and session management: Exploiting weak login and session management.  See our other rules to better security
    • Cross-site scripting (XSS): Executing arbitrary JavaScript on a web page, often by reflecting unescaped user input
    • Insecure direct object references: Exposing internal implementation objects without proper access control
    • Security misconfiguration
    • Sensitive data exposure: Storing sensitive data in a way that can easily be retrieved and abused
    • Missing function level access control: Only applying access control to the UI, not when the secure section is accessed
    • Cross-Site Request Forgery (CSRF): Hijacking a user’s cookies to make requests on their behalf
    • Using components with known vulnerabilities
    • Unvalidated requests and forwards: Redirecting from a current site to an untrusted 3rd party, which may allow phishing to occur

    Other Resources 

    Protecting against these is a large topic in their own right.  There are plenty of resources with information on protecting against these, linked below:

    • Troy Hunt – Protecting your web apps from the tyranny of evil with OWASP 
      This video goes through the OWASP Top 10 in more detail, describing each risk, how to exploit it, and how to protect against it
    • OWASP Top 10 
      The OWASP home page is a little difficult to navigate but contains fantastic information on the risks and how to protect against them. Use the link above to get details on each of the vulnerabilities, with examples on attacking, “Cheat Sheets” for prevention and risk/impact assessment.

  4. Do you store your secrets securely?

    Most systems will have variables that need to be stored securely; OpenId shared secret keys, connection strings, and API tokens to name a few.

    These secrets must not be stored in source control in plain text – it is insecure by nature, and basically means that it is sitting.

    There are many options for managing secrets in a secure way:

    Bad Practices

    Store production passwords in source control protected with the ASP.NET IIS Registration Tool


    • Minimal change to existing process – no need for DPAPI or a dedicated Release Management (RM) tool.
    • Simple and easy to understand


    • Need to manually give the app pool identity ability to read the default RSA key container.
    • Difficult to manage production and non-production config settings
    • Developers can easily decrypt and access the production password.
    • Manual transmission of the password from the key store to the encrypted config file.
    Figure: Bad practice - Overall rating: 2/10

    Use Windows Identity instead of username/ password.


    • Minimal change to existing process – no need for DPAPI or a dedicated RM tool.
    • Simple and easy to understand


    • Difficult to manage production and non-production config settings
    • Not generally applicable to all secured resources. 
    • Can hit firewall snags with Kerberos and AD ports
    • Vulnerable to DOS attacks related to password lockout policies
    • Has key-person reliance on network admin
    Figure: Bad practice - Overall rating: 4/10

    Use External Configuration Files


    • Simple to understand and implement


    • Makes setting up projects the first time very hard.
    • Easy to accidentally check the external config file into source control.
    • Still need DPAPI to protect the external config file.
    • No clear way to manage the DevOps process for external config files.
    Figure: Bad practice -  Overall rating: 1/10

    Good Practices

    Use Octopus/ VSTS RM secret management, with passwords sourced from KeePass


    • Scalable and secure.
    • General industry best practice - great for organizations of most sizes below large corporate.


    • Password reset process is still manual
    • DPAPI still needed.
    Figure: Good practice - Overall rating: 8/10

    Use Enterprise Secret Management Tool – LastPass/ Hashicorp Vault/ etc..


    • Enterprise grade – supports cryptographically strong passwords, auditing of secret access and dynamic secrets
    • Supports hierarchy of secrets
    • API interface for interfacing with other tools.
    • Password transmission can be done without a human in the chain.


    • More complex to install and administer
    • DPAPI still needed for config files at rest
    Figure: Good practice -  Overall rating: 8/10
  5. Do you use a finger scanner to monitor access to secure areas?

    ​​​​​Do you know who is entering your premises, when and how? Keys or key-cards can be expensive, they can be lost and people can loan them to one another without any restriction.

    Finger scanners are a good way of monitoring and restricting access to secure areas. As every person’s fingerprint is unique, so is the access to your building.  There is no physical mechanism for unlocking the doors, which means you do not have to worry about lost keys or unauthorized access and it can keep a log of entry.

    SSW uses an Invixium fingerprint scanner. The user interface is easy to use, you simply hold your finger down on the screen and it will either allow or deny you access. Other fingerprint scanners like E-Key use a swipe function that is less intuitive for visitors. 

    The Invixium integrates well with our Control4 Automation system.

    Scanner 2.jpg
    Bad example - E-Key needs you to swipe your finger down, this is less intuitive
    Scanner 1.jpg
    Good example - Invixium is easy to use, just hold down your finger on the screen to scan


    Rules to Better Control4​

    Better Software Suggestions​

  6. Does your team understand the dangers of social engineering?

    As developers when we think security we commonly become fixated with issues in the code, out of date software versions or incorrectly configured firewalls. However, we miss one glaring vulnerability which there is no patch for... our users.

    Social engineering is a technique which mixes art and science to exploit common human behaviours to compromise information systems. The following is a classic example of social engineering performed over the phone.


    There are numerous examples of social engineering ranging from phone calls, attackers posing as friends on social media, all the way to sophisticated attempts at phishing users with near-perfect clones of popular websites.

    Figure: ‘Do you think the average consumer could spot the phishing site?’ Source: Troy Hunt

    The only solution to social engineering is to train properly and prepare users about the dangers presented by and common techniques used by malicious individuals. For useful information on the topic reference the document ‘Avoiding Social Engineering and Phishing Attacks’ by the United States Computer Emergency Readiness Team  or the Pluralsight course Ethical Hacking: Social Engineering by Troy Hunt .

    With the above in mind, it is important to review regularly the information availed via search engines and standard operating procedures. Furthermore, it can be useful to test the readiness and alertness of staff by performing mock social engineering attacks.

    Take the following situation as an example: the CEO is out of town and decides to use an employee’s laptop left in the office on the weekend, the employee in question is messaged via Skype for their domain password. If the employee is aware of the risks, this poses the company then they would not send the requested credentials and follow proper procedure around reporting a suspected incident.

  7. Do you follow Security Checklists?

    The following checklist is a good example of areas to focus on:
    • Run penetration tests with to check how exposed your servers are
    • Look for passwords in .config and code (SSW Code Auditor can help)
    • Authentication process of identifying who the user is
    • Authorization what the user can do within the application
    • Licensing to control the usage of the software
    • Validation of all inputs in the system (cross site scripting (XSS) and SQL injection)
    • No in memory generation of SQL statements (and are they using a good ORM)
    • Encryption of passwords and any sensitive data
    • Software Licensing protection mechanisms (and a recommendation to a subscription model)
    • Methodologies and best practices to reduce your exposure to hostile attacks
    • Logging who is doing what and when (audit trails)
    There is a more comprehensive list here on GitH​ub: A practical security guide for web developers​.

  8. [DEPRECATED] Do you use built in authentication from MS?

    Assuming you want:

    • Full blown user management
    • Nice Controls eg. Login, Change Password
    • To be able to implement authentication without a Security Consultant to check

    The options are:

    Option 1: ASP.Net Membership provider (original)

    Use their ugly table structure.

    Resilient to errors/attacks/omissions. "Better the devil you know, than the one you don't".

    So if it is simple, straightforward, standardized, integrated well with the existing platform, well documented, and sufficient for your current requirements - why would someone want to go and do something custom?

    No OAuth eg. Facebook

    Option 2: ASP.NET Membership provider (custom)

    (Inherits from Option 1)

    Typically if you want to use your own database tables (even non SQL)

    Easy. A typical implementation of a custom membership or role provider is a simple SELECT query against a database.

    Potentially a glorified ValidateUser/GetRoles method.

    Little messy if you don’t want full blown user management. Then you must leave a number of NotImplementedException methods (because you are not going to administer the store through the provider). In that case implement a base class, leave 28 methods not implemented, implement ValidateUser that takes two strings and returns a bool ;)

    Most clients have more concerns about them making mistakes in the custom security code, that would compromise the security of the application, then about using a bloated existing platform security mechanism correctly (when there are thousands of samples and documentation out there about how to do so correctly).

    Yes to OAuth eg. Facebook

    Hard to unit test.

    Option 3: Universal provider (Updated ASP.NET Membership provider)

    (Inherits from Option 1)

    Use their table structure.

    The default for VS 2012 Web Forms

    Universal Providers are intended for cases where you have an existing ASP.NET Membership Provider and you want to use it with another SQL Server database backend (other than SQL Server).

    Yes to OAuth eg. Facebook (out of the box)

    Option 4: SimpleMembershipProvider (New)

    (Inherits from Option 1)

    Use their table structure.

    The default for VS 2012 MVC 4 templates.

    Yes to OAuth eg. Facebook (out of the box)

    Note: If you need to use for Web Forms see Adding the SimpleMembership provider to an ASP.NET Web Forms app.

    Option 5: Use “Membership Reboot” on GitHub (a Gurus one) (RECOMMENDED)

    A solid, more flexible and open source alternative to the ASP.NET membership provider

    Typically if you want to use your own database tables (even non SQL)

    Description: Think twice about using MembershipProvider (and SimpleMembership)


    This OSS account management library manages these sorts of things for you:

    • PBKDF2 (Proper password storage)
    • Password reset
    • Account lockout for password guessing
    • Account confirmation via email, etc


    • It is multi-tenant
    • It is claims aware (some complicated security thing from Microsoft that will revolutionize security)

    The design is different than ASP.NET Membership in that the security goo is packaged separately from the persistence (the database). You’d not normally need to change the security stuff (though it is extensible).

    You implement a repository if you want a custom storage (or you can just use EF and whatever EF-enabled DB you want).

    Option 6: Roll your own

    Risk, Risk, Risk... Unless you are a security consultant you are likely to leave a security hole.

    Of course you should not roll your own security. This option is building your own authentication and authorization routines to tie into FormsAuth (instead of using providers).

    The ASP.NET membership provider is wired in at a deep level in the ASP.NET pipeline. A roll your own solution loses you the benefits of leveraging this integration eg. In Silverlight and the WebAPI

    An example of completely removing ASP.NET Membership Providers: Kicking ASP.NET Providers to the Curb - And that actually works fine, but with one big, ugly, drawback. The site is able to authenticate and authorize as needed, but you drop in a few .ashx or other things like Elmah, CacheManagement, etc, and then tried to restrict access to them... it obviously is not able to.

    Note: Gurus use Windows Identity Foundation (and IdentityModel).