Skip to content

fix: content and formatting issues #94

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions modules/1-introduction.livemd
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,13 @@

Found in this series of modules is a curriculum for teaching Secure Coding concepts and ideas centered around the Elixir ecosystem. Core principles of Application Security have been sourced from other available resources within the community and pieced together into this Elixir Livebook format to allow for an interactive spin.

It is worth stating that this material is a work in progress and is open to contributions in order to make this the one-stop shop for Developer Secure Coding Training (for Elixir). The initial training material was originally crafted by the Product Security team at [Podium](https://www.podium.com/) and as such, contains very opinionated lessons to help contribute to the Secure SDLC of Podium's engineers. The more general this material can be made through outside contributors, the more secure we can make the Elixir community.
It is worth stating that this material is a work in progress and is open to contributions in order to make this the one-stop shop for Developer Secure Coding Training (for Elixir). The initial training material was originally crafted by the Product Security team at [Podium](https://www.podium.com/), but is now maintained by the [Erlang Ecosystem Foundation](https://erlef.org).

## Who This Is For

This curriculum is for any Software Developer / Engineer / Maker / Hacker looking to better their own knowledge of the Web Application Security space, especially as it pertains to Elixir Phoenix applications.

This Training material is also ideally used in an educational environment for organizations to level up their Engineering teams Security knowledge. Quiz questions have been crafted within and an auto-grader that can be deployed in the CI/CD pipeline for local forks of this repo will be made available soon.
This Training material is also ideally used in an educational environment for organizations to level up their Engineering teams Security knowledge. Quiz questions have been crafted within and are graded directly within each Livebook.

## How To Use This Livebook

Expand Down
59 changes: 32 additions & 27 deletions modules/11-authentication.livemd
Original file line number Diff line number Diff line change
@@ -1,16 +1,17 @@
# ESCT: Part 11 - Authentication
# 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.
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.
One of two things follow:

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.
* 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.

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.
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

Expand All @@ -26,19 +27,19 @@ Authentication is the mechanism that helps guard the front door of an applicatio

### 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.
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.
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.
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.
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):

Expand All @@ -52,18 +53,19 @@ Authentication mechanism can be simple or complex. Security industry best pract

### 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.
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 its name suggests, it has evolved for use in the authentication and authorization mechanisms. A very good resource that describes the OAuth in context of its 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.
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>
### <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

Expand All @@ -73,14 +75,11 @@ There are four primary entities involved with the OAuth protocol: requesting, se
-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)

```
[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.

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

Expand All @@ -89,43 +88,46 @@ Why use JWT? For post authentication authorization, JWTs can be signed and encry
### <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.
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.
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 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.
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
Expand All @@ -138,15 +140,17 @@ Authentication Issues, Weaknesses, Failures make an appearance on multiple lists
OWASP Top 10 for Web Applications A07:2021-Identification and Authentication Failures (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, its 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.
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, its 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
Expand Down Expand Up @@ -185,6 +189,7 @@ IO.puts(answer)
```

### 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
Expand Down
Loading