Forem: Shamsuddeen Abdulkadir

[Boost]

Shamsuddeen Abdulkadir — Sun, 19 Oct 2025 16:57:43 +0000

Shamsuddeen Abdulkadir

Oct 19 '25

Laravel APP_KEY vs Password Hashing: What Every Developer Should Know About Encryption & Hashing.

#security #laravel #webdev #php

Comments

3 min read

Laravel APP_KEY vs Password Hashing: What Every Developer Should Know About Encryption & Hashing.

Shamsuddeen Abdulkadir — Sun, 19 Oct 2025 16:57:25 +0000

It was 1:45PM on a Sunday afternoon. I was having a discussion about TLS/SSL with my wife, who happened to be a Senior Cybersecurity Consultant at one of the Big-Fours, when the topic of hashing and encryption crept into the conversation. Most of my thoughts during the conversation revolved around software development — I mean, it is what I do.

I have been developing solutions with the Laravel framework for a while now, but I have little idea of how encryption works in detail. All I know is that it uses the key generated during installation in the .env file, APP_KEY, for encryption. I also know about secure password hashing using Bcrypt driver: Hash::make('password').

However, I never paid detailed attention to the topic of encryption and its difference from hashing, especially in relation to Laravel and security in software systems. I was had a misconception that the app key is also used in password hashing before this whole conversation — just like the creator of the Laravel framework, Taylor Otwell, clarified years back on Twitter, now X.

Below is a breakdown of my findings about Encryption, Hashing and the difference between the two. And also how they're utilized in Laravel framework.

Encryption

This is said to be a two-way function, meaning whatever data you encrypt can be decrypted. This is what the env variable APP_KEY is used for in Laravel. It is used for securing storage such as cookies, session data, API tokens, and more.
A simple example is; When a user is authenticated in a Laravel Application, the cookies and session data is encrypted using the current APP_KEY. When a new key is generated, then the user gets automatically logged out of the application.
Below is a simple example from the Laravel documentation on encrypting a string:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Crypt;

class DigitalOceanTokenController extends Controller
{
    /**
     * Store a DigitalOcean API token for the user.
     */
    public function store(Request $request): RedirectResponse
    {
        $request->user()->fill([
            'token' => Crypt::encryptString($request->token),
        ])->save();

        return redirect('/secrets');
    }
}

Hashing

Hashing, on the other hand, is a one-way function. This means that when data is hashed, it cannot be reversed to its original form. This is used mainly to store data that can be verified but not in its original form. For example, hashing a user's password and then storing the hashed form of the password in the database. Whoever that has access to the records cannot tell what the password is because it hashed. And then during Authentication, the password entered by the user will be hashed first, and then compared with the one stored in database.
The default hashing driver is used in the Laravel framework is Bcrypt.
Below is a very snippet from the documentation that depicts the most common hashing implementation:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;

class PasswordController extends Controller
{
    /**
     * Update the password for the user.
     */
    public function update(Request $request): RedirectResponse
    {
        // Validate the new password length...

        $request->user()->fill([
            'password' => Hash::make($request->newPassword)
        ])->save();

        return redirect('/profile');
    }
}

I hope it is an interesting read and discovery for you as it was for me, that Encryption and Hashing are fundamentally different security concepts with different use cases in Laravel. See you on the next one!

Load Testing a Non-API Laravel Web Application with Sanctum Session-Based Authentication Using K6

Shamsuddeen Abdulkadir — Sun, 19 May 2024 21:23:54 +0000

The idea for this post came from a project I handled at work, where I needed to load test a high-demand platform. I initially started with Jmeter based on colleagues' recommendations but encountered issues with Sanctum session authentication tokens. Despite multiple attempts, I couldn't resolve the problem.

The aim of this tutorial is not to introduce you to Load Testing or K6 but rather, to offer a solution for those facing similar issues with passing Sanctum session token in their tests, so they wouldn't go through the stress I experienced.
Upon researching about other alternatives to Jmeter, I discovered K6, an open-source load testing tool.

Testing an endpoint that required Sanctum session-based authentication proved challenging, particularly when handling the XSRF-TOKEN. I searched extensively for solutions on integrating Sanctum with K6 but found none. This led me to create my own approach, which I'm sharing here.

Below is the sample K6 test code and it is easy to understand for those with basic understanding of K6 and Javascript.

import { parseHTML } from 'k6/html';
import { sleep, group, check } from "k6";
import http from 'k6/http';

export const options = {
    stages: [
        { target: 50, duration: '1m' },
        { target: 100, duration: '0' },
        { target: 200, duration: '1m30s' },
    ],
}

// Login credentials
const jsonData = JSON.parse(open('./data.json')).users;

export default function main() {
    let response;
    let token;

    group('get login page', function () {
        response = http.get('https://your-domain/login');

        let xsrfTokenValue = null;
        let cookies = response.headers['Set-Cookie'];
        if (cookies) {
            let cookieArray = cookies.split(';');
            cookieArray.forEach(cookie => {
                if (cookie.includes('XSRF-TOKEN')) {
                    xsrfTokenValue = cookie.split('=')[1].replace(/%3D$/, ''); // Remove '=%3D' from the end
                }
            });

            token = xsrfTokenValue;
        }

        check(response, {
            'is status 200': (r) => r.status === 200,
            'XSRF-TOKEN exists': (t) => t !== null,
        });
    });

    sleep(10);

    group('post login page', function () {

        const payload = JSON.stringify({
            username: jsonData[0].username,
            password: jsonData[0].password,
        });

        const params = {
            headers: {
                Connection: 'keep-alive',
                'Content-Type': 'application/json',
                'X-XSRF-TOKEN': token,
            },
        };

        const res = http.post('https://your-domain/login', payload, params);
        check(res, {
            'is status 200': (r) => r.status === 200,
            'is correct URL': (r) => r.url === 'https://your-domain/welcome-page'
        });
    });

    sleep(10);
}

I hope this solution helps you overcome the challenges of handling Sanctum session-based authentication in your load testing.
If you have any questions or need further clarification, feel free to drop a comment. Happy testing!

Cheers!

SOLID Principles in Laravel: A Beginner's Series

Shamsuddeen Abdulkadir — Thu, 28 Mar 2024 22:16:33 +0000

Robert C. Martin, also known as Uncle Bob, emphasizes in his book Clean Architecture the importance of good code as the foundation of good software systems. He compares well-made code to high-quality bricks in building construction. Even with excellent architectural plans, poorly made bricks can undermine the entire structure. On the other hand, well-made bricks can still result in a messy construction if not assembled properly. This is where SOLID principles play a crucial role.

SOLID is an acronym representing five fundamental principles in object-oriented programming and design. Let's break it down:

S stands for Single Responsibility Principle (SRP)
O stands for Open/Closed Principle (OCP)
L stands for Liskov Substitution Principle (LSP)
I stands for Interface Segregation Principle (ISP)
D stands for Dependency Inversion Principle (DIP)

These principles, coined by Robert C. Martin, provide guidelines for writing clean, maintainable, and extensible code. Each principle focuses on a specific aspect of software design, aiming to improve modularity, flexibility, and scalability. Understanding and applying these principles can lead to more robust and adaptable software systems.

Single Responsibility Principle
In this series kickoff, we'll explore SRP with example using PHP & Laravel framework, showcasing how it fosters cleaner, more maintainable code.
The Single Responsibility Principle (SRP) emphasizes that a class or method should have only one reason to change, meaning it should have a single responsibility or purpose. By adhering to SRP, we ensure that each entity in our codebase is focused on doing one thing well, making our code more maintainable, understandable, and flexible.

Imagine writing a Laravel controller for product management that not only validates & store product data but also dispatches email notifications to interested customers.

<?php

namespace App\Http\Controllers;

use App\Models\Product;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Mail;
use App\Mail\ProductRequestedNotification;

class ProductController extends Controller
{
    public function store(Request $request)
    {
        // Validation rules
        $validatedData = $request->validate([
            'name' => 'required|string|max:255',
            'description' => 'required|string',
            'price' => 'required|numeric|min:0',
            'quantity' => 'required|integer|min:0',
            'email' => 'required|email',
        ]);

        // Create new product
        $product = Product::create([
            'name' => $validatedData['name'],
            'description' => $validatedData['description'],
            'price' => $validatedData['price'],
            'quantity' => $validatedData['quantity'],
        ]);

        // Send notification to customer
        Mail::to($validatedData['email'])->send(new ProductRequestedNotification($product));

        // Return success response
        return response()->json(['message' => 'Product stored successfully'], 200);
    }
}

In the provided example, the ProductController is handling multiple responsibilities, including data validation, product storage, and email notification. This violates the Single Responsibility Principle (SRP), which states that a class should have only one reason to change.

To adhere to SRP and improve the controller's clarity and extensibility, we can refactor it to delegate each responsibility to separate classes. This separation of concerns enhances maintainability and allows for easier extension in the future:

Request Validation: Extract the validation rules to a separate request class.
Product Creation: Move the product creation logic to a service class.
Notification: Handle the notification logic in a separate class.

First, create a new Form Request class using the artisan command:
php artisan make:request StoreProductRequest

This will generate a new file StoreProductRequest.php in the app/Http/Requests directory.

Open the StoreProductRequest.php file and update the rules() method with the validation rules:

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class StoreProductRequest extends FormRequest
{
    public function authorize()
    {
        return true; // Authorization logic can be added if needed
    }

    public function rules()
    {
        return [
            'name' => 'required|string|max:255',
            'description' => 'required|string',
            'price' => 'required|numeric|min:0',
            'quantity' => 'required|integer|min:0',
            'email' => 'required|email',
        ];
    }
}

To create the ProductService class, follow these steps:

Navigate to the app/Http/ directory in your Laravel application.
Create a new folder named Services if it doesn't exist already.
Inside the Services folder, create a new file named ProductService.php.
Open the ProductService.php file and add the following code:

<?php

namespace App\Services;

use App\Models\Product;

class ProductService
{
    public function create(array $data): Product
    {
        return Product::create([
            'name' => $data['name'],
            'description' => $data['description'],
            'price' => $data['price'],
            'quantity' => $data['quantity'],
        ]);
    }
}

Lastly, we will generate a Laravel Notification

<?php

namespace App\Notifications;

use App\Models\Product;
use Illuminate\Bus\Queueable;
use Illuminate\Notifications\Notification;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Notifications\Messages\MailMessage;

class ProductRequestedNotification extends Notification implements ShouldQueue
{
    use Queueable;

    protected $product;

    public function __construct(Product $product)
    {
        $this->product = $product;
    }

    public function via($notifiable)
    {
        return ['mail'];
    }

    public function toMail($notifiable)
    {
        return (new MailMessage)
            ->line('Your product request has been received successfully.')
            ->line('Product Name: ' . $this->product->name)
            ->line('Description: ' . $this->product->description)
            ->line('Price: ' . $this->product->price)
            ->line('Quantity: ' . $this->product->quantity);
    }
}

Here's what the ProductController looks like after refactoring:

<?php

namespace App\Http\Controllers;

use App\Http\Requests\ProductRequest;
use App\Services\ProductService;
use App\Notifications\ProductRequestedNotification;

class ProductController extends Controller
{
    protected $productService;

    public function __construct(ProductService $productService)
    {
        $this->productService = $productService;
    }

    public function store(ProductRequest $request)
    {
        // Create new product
        $product = $this->productService->create($request->validated());

        // Send notification to customer
        $product->notify(new ProductRequestedNotification($product));

        // Return success response
        return response()->json(['message' => 'Product stored successfully'], 200);
    }
}

With this refactoring, the ProductController is now responsible only for handling HTTP requests and responses, while the validation rules are encapsulated in the StoreProductRequest class, the email notification is handled by ProductRequestedNotification class, and the business logic for creating a product is handled by the ProductService class. This separation of concerns improves code readability, maintainability, and testability.

In the upcoming part of the series, we'll delve into another fundamental principle: the Open/Closed Principle.