Would you like to see your link here? Contact us

Notesclub

created by hec & contributors

terms privacy

ESCT: Part 11 - Authentication

modules/11-authentication.livemd

The Erlang Ecosystem Foundation

@erlef

elixir-secure-coding

Share to X

Share to Bluesky

More notebooks

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.

Confusion with Authorization and Access
Multi-factor Authentication
Token-Based Implementations
Sessions
Authentication and Security Concerns
Prevention and Countermeasures
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 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.

Example

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.

Example / Quiz

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

Quiz

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