Create 11-authentication.livemd

modules/11-authentication.livemd

@@ -0,0 +1,194 @@
+# ESCT: Part 11 - Authentication 
+
+## Introduction
+
+Authentication is the process of establishing that an entity, whether person or machine, is who they say they are. In this process the entity starts by "knocking on the door", and presenting their id card and credentials when prompted. 
+
+One of two things follow: 
+- The authentication attempt is successful and further communication including the granting of access can proceed. 
+- Authentication fails and other that notifying the entity of the failure, no further communication proceeds and no access is granted. 
+
+Imagine you get a knock on your door. You ask who it is, and the person on the other side says you have a package delivery.  In fact, you're not expecting a package and you can see the person is not wearing a uniform and doesn't have a package in their hands.  Something doesn't match.  They don't seem to be who they say they are and so, you don't open the door. 
+
+Authentication is the mechanism that helps guard the front door of an application.  It's the mechanism that helps control who gets into your system and if they are there legitimately. 
+
+## Table of Contents
+
+* [Confusion with Authorization and Access](#confusion-with-authorization-and-access)
+* [Multi-factor Authentication](#multi-factor-authentication)
+* [Token-Based Implementations](#token-based-implementation)
+* [Sessions](#sessions)
+* [Authentication and Security Concerns](#authentication-and-security-concerns)
+* [Prevention and Countermeasures](#prevention-and-countermeasures)
+* [Quiz](#quiz)
+
+## Confusion with Authorization and Access
+
+### Description
+
+Thinking back to the example above, authentication is establishing an entity is who they say they are.  For applications, this means, the user who is attempting to login, is the user who created and has control over the account.  But most applications have multiple levels of users, those with maximum access/privileges to move around and modify the application freely, and those with more restricted access. 
+
+Once an entity has been authenticated, then they are granted access but when implemented in an application/system, this often appears to happen in a single step. Users login and if you get a successful response you also get access to the application.  Access immediately follows Authentication, but how much access an entity is allowed and the actions they are permitted to, is authorized, to perform are governed by a set of permissions or access controls referred to as Authorization, which is often managed by a token or similar credentials. 
+
+During the authentication and authorization process, validity of credentials and level of access are checked. Then, depending on the architecture of the system or application, once an entity is authenticated, is granted access,  subsequent activity/interactions need to be tracked/attributed to the same entity.  This functions like a hand stamp for re-entry to an event or amusement park accept it is unique to you. For applications, this means setting up and tracking an authenticated user's session, and this is often done using some kind of token, sometimes the same token that gets issued for access.
+
+Authorization, Identity, Credentials, Access, Access Controls, Permissions, Session and Session Management are all terms you will come across when implementing Authentication in applications.  While each has distinct definitions, consider them as mutually interactive contributors to an integrated system that works to allow into an application only what is verified and trusted, tracks and monitors the activity of what's been allowed in, and ensures what does get in, only has access to what they absolutely need in order to perform their specific function.  How these are implemented and their specific configuration is unique to the design of each application. 
+
+## Multi-factor Authentication
+
+### Description
+
+Multi-factor Authentication (MFA) is a way of implementing authentication so that more than one aspect of an entity is checked when it presents itself. from the initial simple example, checking both the information on the id card (something they have) and asking the entity to verbally state their name (something they know), for instance. 
+
+When implemented in applications, these aspects are referred to as factors and Authentication can be implemented using one of these factors (single-factor) or 2 or more (multi-factor):
+
+Something you know/that is in your brain - Password
+Something you have/possess/have physical or digital access to - Code generated by outside party; key
+Something you are/something unique to you as a person - fingerprint, facial recognition, other biometrics, palm scan, retinal scan
+
+Authentication mechanism can be simple or complex.  Security industry best practices recommend implementing multi-factor authentication wherever possible.
+
+## Token-based Implementation
+
+### Description
+
+We mentioned earlier how both authorization (access) and sessions can be handled using tokens.  Access Tokens are built so that they contain information about what an authenticated user does and does not have access to, for how long, and they can also be used to manage the user's persistence/ongoing interactions with the application in a session.  
+
+Tokens are long strings of random characters used to identify an entity, session, as a badge for access and are usually generated by some token generating code, service or server.  In token-based implementations, at a highlevel the application or service generates tokens, assign token to users after they have been authenticated, check token validity as users access and use application functionality/features, and end/renew sessions by expiring and refresh tokens.
+
+### OAuth
+Open Authorization(OAuth) is a protocol in which a multi-step arrangement generates a token for a specific users, the user presents as a credential in lieu of a password. There is an extra server (authorization/token generating service or server) that after a user authenticates with it, it generates a token, and brokers authentication/authorization between initial entity and a resource.
+
+Originally built for authorization, as it's name suggests, it has evolved for use in the authentication and authorization mechanisms.  A very good resource that describes the OAuth in context of it's history and current implementations is here: https://www.youtube.com/watch?v=996OiexHze0
+
+Why use OAuth? When users need access to third party services, outside of your environment where you don't want to share your credentials with those third parties.  In OAuth protocol/architecture, an authorization service brokers access and grants users an access token to present, in place of credentials. 
+
+### <span style="color:blue;">Example</span> 
+
+There are four primary entities involved with the OAuth protocol: requesting, service one, service 2, intermediary server that handles issuing tokens that get presented in lieu of credentials.  At a very high level, the flow looks something like
+
+-User Authenticated into Application/Service X
+-Application/Service X prompts user if they want to login using social media account credentials
+-User Logs into social media account/other service
+-Authorization Server/Service Generates Access Token 
+-Service X sends Token for limited access to Social Media Account (instead of sharing credentials)
+
+
+``` 
+[OAuth2.Client module ](https://hexdocs.pm/oauth2/OAuth2.Client.html)
+
+```
+
+### JWT
+JSON Web Tokens (abbreviated JWT, pronounced "jot") are multi-use tokens for authentication and session management.  JWTs have three components, header contains information identifying type of token and algorithm used for the signature, payload/body that contains data about the disposition of the token, signature - which serves as an integrity check to establish if the token has been modified or tampered with. 
+
+Tokens, like other authentication credentials, etc. must be protected in transit and at rest and can be Base64 encoded and cryptographically signed
+
+Why use JWT? For post authentication authorization, JWTs can be signed and encrypted which helps establish trust.  These tokens place little stress on the authentication and authorization mechanisms and help with implementing access controls throughout the application.
+
+### <span style="color:blue;">Example</span> / <span style="color:red;">Quiz</span>
+
+Create/Generate Token
+```
+
+
+```
+
+Validate Token
+```
+def connect(%{"authorize" => token}, socket, _connect_info) do  //
+  case JwtChecker.validate_token(token)do
+  ...
+  ...
+```
+### References
+https://dev.to/onpointvn/implement-jwt-authentication-with-phoenix-token-n58
+(https://hexdocs.pm/guardian/Guardian.Token.Jwt.html)
+https://elixirschool.com/blog/jwt-auth-with-joken/
+
+
+## Sessions
+
+### Description
+
+Authentication is the first step a user must complete to access a secure application/data. Once an entity is authenticated, subsequent activity/interactions need to be tracked as belonging to the same entity.  
+
+Some applications do this by establishing and managing a session. Other applications are "session-less" and required a different approach for keeping the application's "knowledge" of what a user is doing while they use an application. 
+
+For session-less applications, once a user authenticates, the server assigns and sends a token to their client.  For any following requests, the client sends their token in each request, like with JWTs discussed previously.  The server only checks the validity of the token.
+
+In session oriented applications, one the user authenticates, information in subsequent requests are compared to session information kept on the server. 
+
+In a way, this is like a museum visit. A session is like showing your membership card or ticket for the day.  Generally you can come and go on your day pass (they'll probably stamp you hand if you leave but you can get back in no problem).  Once the museum closes, the session is over and you have to leave and come back another day.  If you have a membership or ticket for multiple visits, you have to show your card/ticket at the door again.
+
+Session-less, sometimes referred to as "fire and forget it" is like purchasing a single day pass with cash.  Your name probably isn't in the system and if you come back a month later to buy another day pass, there's no record of you having been there previously.  (For simplicity we'll ignore any tracking.)  If you have a membership card with your name, however,  and if you're paying cash, probably can't track you individually.
+
+## Authentication and Security Concerns
+
+An application's authentication mechanism is a critical component.  If not securely designed, it can provide an attack vector for malicious actors to gain access to legitimate user accounts, privileged application features, and sensitive data. 
+
+-Authentication, credentials, should never be stored in cleartext, nor hardcoded in source code
+Credential Stuffing Attacks
+Security concerns/examples of multi-factor authentication getting hacked
+Multi-factor authentication (MFA) fatigue attack - aka MFA Bombing - aka MFA Spamming
+Bypassing MFA
+JWT token vulnerabilities
+
+Authentication Issues, Weaknesses, Failures make an appearance on multiple lists
+OWASP Top 10 for Web Applications A07:2021-Identification and Authentication Failurs (used to be called Broken Authenticication
+
+## Prevention and Countermeasures
+Use built and tested authentication mechanisms in your code language framework.  
+
+Authentication is a key component of an application but given its integration with some of the other concepts mentioned in this module, it's implementation in your products can become complex. This module touched on some of the highlights but please refer to the references below for extensive explanations of authentication and related. 
+
+### <span style="color:red;">Quiz</span>
+
+**Which of the following OWASP Top 10 Web Application Security Risks are related to the abuse of credentials or flaws in mult-factor authentication implementation?**
+
+*Uncomment the line with your answer*
+```
+
+# A02:2021-Cryptographic Failures
+# A05:2021-Security Misconfiguration
+# A07:2021-Identification and Authentication Failures
+# A08:2017-Insecure Deserialization
+
+IO.puts(answer)
+
+```
+
+**Which two are examples of a credential that can be used in an application's authentication process?**
+
+*Uncomment the line with your answer*
+
+```
+# token
+# api call
+# session
+# username and password
+
+IO.puts(answer)
+
+```
+
+**Which statement best characterizes how an entity trying to be properly authenticated goes about it?**
+
+```
+*Uncomment the line with your answer*
+
+# Hello, I just came from X street and would like to enter your establishment. I am who I say I am and I can show you proof.  May I enter?
+# Let me in, now! Let me in , now! Let me in, now!!!!! 
+# Trust me, I'm harmless
+# Yes, I know that id doesn't look like me but my friend said I can use it so it's ok
+
+```
+
+### References
+https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
+https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
+https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/06-Session_Management_Testing/README
+https://owasp.org/www-community/attacks/Credential_stuffing
+https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/10-Testing_JSON_Web_Tokens
+
+[**<- Previous Module: Secure SDLC Concepts**](./3-ssdlc.livemd) || [**Next Module: Elixir Security ->**](./5-elixir.livemd)