Intro: Why Every App Needs Threat Modeling And Why STRIDE I’ve been meaning to write this post for a long time. Not because STRIDE Threat Modeling are the hottest buzzwords in cybersecurity—they aren’t. And not because threat modeling is some shiny new technique—it’s not. But because if you’re building or defending any system—especially something as deceptively simple as a chat app—threat modeling is non-negotiable. Whether you're knee-deep in SecOps, defining IAM policies, tuning your SIEM, or crafting detection logic, you’ve got one mission: protect the stuff that matters. That means user data, privacy, service uptime, and reputation and so on. And if we don't design with threats in mind, we're just building breach bait with good intentions. So why STRIDE? Because STRIDE gives us a practical lens to view risk before the attacker does. Instead of reacting to CVEs or chasing zero-days, STRIDE helps you think like a malicious actor while you’re still sketching your architecture in a whiteboard session or writing that controller code. In this post, I am going to use STRIDE threat modeling to walk through a seemingly simple application—a chat app—and uncover the kinds of security holes that quietly turn into breach reports. You’ll see just how quickly things go sideways when we forget to ask, “What could go wrong here?” But first, let's talk about the app we're modeling. Our Target: A Chat App Let’s keep it humble. No machine learning, no blockchain, no AI buzzwords glued onto CRUD. Just a straightforward web-based chat application. Here’s what it does: User Registration: Email + password Login System:…

Greetings to all you geeks out there! It's a pleasure to have you here at geekcoding101.com! With almost 20 years immersed in the vibrant world of Linux and security domain, I've encountered a myriad of tools and technologies that have shaped my journey. Today, I'm excited to introduce you OpenSSL and Certutil—two indispensable utilities that play pivotal roles in managing digital certificates and encryption. Whether you're safeguarding your web servers or securing communications, understanding these tools is crucial. I've distilled my insights and tips into this post, aiming to arm you with the knowledge to leverage these powerful utilities effectively. Enjoy! Openssl OpenSSL is an open-source software library that provides a robust, commercial-grade, and full-featured toolkit for SSL and TLS protocols, as well as a general-purpose cryptography library. It is widely used by internet servers, including the majority that implement secure web (HTTPS) connections, as well as in countless other security-sensitive applications. Here are some key aspects of OpenSSL: Core Features Query Information Query on Private Key: openssl rsa -in privatekey.pem -check Query All Information: openssl x509 -in certificate.pem -text -noout Query Subject: openssl x509 -in certificate.pem -subject -noout Query Validity: openssl x509 -in certificate.pem -dates -noout Query Purpose: openssl x509 -in certificate.pem -purpose -noout Example: Certificate purposes: SSL client : No SSL client CA : Yes SSL server : No SSL server CA : Yes Netscape SSL server : No Netscape SSL server CA : Yes S/MIME signing : No S/MIME signing CA : Yes S/MIME encryption : No S/MIME encryption CA : Yes CRL signing : No CRL…

Introduction JSON Web Tokens (JWTs) play a crucial role in web application security. In this blog, we walkthrough the concept of JWT, focusing on the different types of claims, the structure of a JWT, and the algorithms used in signatures, and finally I will implement JWT authentication from scratch in Node.js and Express.js. This is my 4th article in Auth101! It’s 2024 now! Looking forward to a wonderful year filled with cool tech updates, new tricks in cyber security, and a bunch of fun coding adventures. I can’t wait to dive into more authentication topics with you all 😃 Understanding JWT JSON Web Tokens (JWTs) originated as a compact and self-contained way for securely transmitting information between parties as a JSON object. Defined in RFC 7519, JWTs have become a widely adopted standard in the field of web security for their simplicity and versatility. A JWT is a string comprising three parts separated by dots (.): Base64Url encoded header, Base64Url encoded payload, and signature. It typically looks like xxxxx.yyyyy.zzzzz. Let’s deep dive into the three parts: Header, Payload, and Signature. Header The header typically consists of the token type and the signing algorithm, such as HMAC SHA256 or RSA. For example:{ "alg": "HS256", "typ": "JWT" } Payload The payload contains claims, which are statements about an entity and additional metadata. Claims are categorized into registered, public, and private claims. The later two are for custom claims. Public claims are collision-resistant while private claims are subject to possible collisions. In a JWT, a claim appears as a name/value pair where the name is always a string…

Brief Description The OAuth 2.0 authorization code flow is a secure and widely adopted method for obtaining access tokens to access user resources on behalf of the user. Steps Here's a summary of the steps in the authorization code flow: To clarify, in the authorization code flow, the authorization endpoint issues an authorization code to the client application upon user consent, not an access token directly. Why Authorization Code Flow Not Issue Access Token Directly? The OAuth 2.0 authorization code flow is designed to enhance security and minimize certain risks associated with transmitting sensitive information, such as access tokens, through the user's browser or mobile device. Here are some reasons why the authorization endpoint issues an authorization code instead of an access token directly: Overall, by issuing an authorization code instead of an access token directly, the OAuth 2.0 authorization code flow aims to improve security, reduce exposure to sensitive information, and provide a clear separation of concerns in the authentication and authorization process. Benefits of Authorization Code Flow

List of Grant Types Below is a table summarizing the different grant types in OAuth 2.0 along with brief descriptions and recommendations regarding their use: Grant Type Description Recommendation Authorization Code The most commonly used flow in OAuth 2.0. It involves the exchange of an authorization code for an access token. Suitable for server-side web applications and confidential clients. Recommended for web applications and confidential clients. Implicit Designed for user-agent-based clients (e.g., browser-based JavaScript applications). Access token is returned directly to the client without an authorization code exchange. Deprecated due to security concerns. Resource Owner Password Credentials Allows the client to exchange the user's username and password for an access token directly. Generally discouraged due to security implications and lack of federation support. Not recommended unless unavoidable legacy scenarios. Client Credentials Enables clients to directly exchange client credentials (client ID and client secret) for an access token. Typically used for machine-to-machine communication. Recommended for machine-to-machine communication. Refresh Token Allows clients to request a new access token without requiring the user to re-authenticate. It's not a grant type but rather a mechanism for obtaining new access tokens. Recommended for long-lived sessions and offline access. It's important to note that while some grant types may be deprecated or discouraged due to security concerns or lack of use cases, their applicability can vary based on specific requirements and use cases. However, it's generally recommended to adhere to best practices and use the authorization code flow whenever possible for enhanced security and flexibility. Is PKCE A Grant Type? No, PKCE (Proof Key for Code…

Introduction In this blog post, we will dive into HTTP Basic Authentication, a method rooted in the principles outlined in RFC 7617. It’s worth noting that, the RFC specification defines the use of the “Authorization” header in HTTP requests to transmit the credentials. The credentials are typically sent as a Base64-encoded string of the form username:password. It also describes how servers should respond with appropriate status codes (e.g., 401 Unauthorized) when authentication fails. Step 1: Setting Up the Node.js and TypeScript Environment Please refer to the steps explained in our previous blog post Password Authentication In Node.Js: A Step-By-Step Guide at Step 1: Setting Up the Node.js and TypeScript Environment. Step 2: Creating the Server usersData.ts In this file, we define a simulated database of users with their hashed passwords using bcrypt. Each user has a username and a password field. This file acts as our database for the sake of this example. The usage of bcrypt also has been explained in Password Authentication In Node.Js: A Step-By-Step Guide already. interface User { username: string; password: string; } const users: User[] = []; export default users; basicAuthMiddleware.ts This file contains the basic authentication middleware. The middleware is responsible for authenticating users based on the credentials provided in the Authorization header. It uses bcrypt to compare the provided password with the hashed password stored in the usersData.ts file. import { Request, Response, NextFunction } from 'express'; import { Buffer } from 'buffer'; import bcrypt from 'bcryptjs'; interface User { username: string; password: string; } const basicAuthMiddleware = (users: User[]) => async (req: Request, res: Response, next: NextFunction) => { try { const authHeader…

Introduction Password-based authentication remains one of the most common and widely used methods to verify user identity in various online systems. It involves users providing a unique combination of a username and password to gain access to their accounts. Despite its prevalence, password-based authentication comes with security challenges, as weak or compromised passwords can lead to unauthorized access and data breaches. In this blog, I will guide you exploring password-based authentication from an easy to medium level, implementing password hashing in a Node.js and TypeScript environment. By the end of this hands-on tutorial, you will have a better understanding of how Password-based authentication works in your applications. Step 1: Setting Up the Node.js and TypeScript Environment To get started, ensure you have Node.js installed on your machine. Create a new project folder and initialize it with a package.json file. Here is the steps to show what I’ve done on Mac: brew install npm httpie mkdir password-auth cd password-auth npm init -y npm install -g ts-node npm install body-parser bcryptjs express --save npm install @types/bcryptjs @types/express @types/body-parser --save Setting up the programming environment is no doubt crucial, but let’s be honest, it can be a bit daunting. In my tutorials, I will try to make sure not to leave you hanging. I love providing comprehensive explanations, even for the simple tasks or commands. Let’s make this setup process a breeze together! I genuinely hope you find it helpful and that it keeps you smoothly sailing through the tutorial 🤓 Let’s walk through above commands. ▹ 1. brew is the package manager for macOS…