Forem: H.M.Ashis Rahman

How I Built My Own Offline 2FA Authenticator App (A Weekend Android Project)

H.M.Ashis Rahman — Thu, 23 Oct 2025 17:36:58 +0000

Introduction: The Offline Mystery of 2FA

We all rely on 2-Factor Authentication (2FA) for enhanced security. Apps like Google Authenticator, Authy, or Microsoft Authenticator are staples on our phones. But have you ever stopped to wonder how they generate those constantly changing, time-sensitive codes without an internet connection?

That question sparked my latest weekend project. I decided to pull back the curtain and build my very own 2FA authenticator app for Android, focused specifically on implementing the Time-based One-Time Password (TOTP) algorithm. It was a fascinating dive into cryptography, time synchronization, and mobile development.

What is TOTP and How Does It Work?

Before we jump into the code, let's quickly demystify TOTP. At its core, TOTP (Time-based One-Time Password) is a method that uses a shared secret key and the current time to generate a unique, temporary verification code.

The magic relies on both the authentication server and your authenticator app having:

A Shared Secret Key:

A unique, random string generated during the account setup (when you scan a QR code).

A Common Understanding of Time:

While not perfectly synchronized to milliseconds, both need to agree on roughly the same "time window" (e.g., a 30-second interval).

Using these two inputs, they can independently generate the same OTP at any given 30-second interval. When you enter the code from your app, the server performs the same calculation. If the codes match, you're authenticated!

My Project: Architecture Overview

Here's a breakdown of the simple architecture I implemented for this project:

Authentication Server (Conceptual/Simulated):

Generates a unique secret key for a user.

Stores this secret key securely in a database.

Generates a QR Code that encodes this secret key (often using a otpauth:// URI format). This QR code is what the user scans to "enroll" their device.

Android Authenticator App (The Star of the Show):

QR Code Scanner: Captures the otpauth:// URI
containing the secret key.

Secret Key Storage: Securely stores the captured secret key on the device.

TOTP Generator: Uses the stored secret key and the device's current time to continuously calculate and display the current 6-digit OTP, refreshing every 30 seconds. Here's a breakdown of the simple architecture I implemented for this project:

Authentication Server (Conceptual/Simulated):

Generates a unique secret key for a user.

Stores this secret key securely in a database.

Generates a QR Code that encodes this secret key (often using a otpauth:// URI format). This QR code is what the user scans to "enroll" their device.

Android Authenticator App (The Star of the Show):

1.QR Code Scanner: Captures the

otpauth:// URI
containing the secret key.

Secret Key Storage: Securely stores the captured secret key on the device.

TOTP Generator: Uses the stored secret key and the device's current time to continuously calculate and display the current 6-digit OTP, refreshing every 30 seconds.

Key Implementations

I leveraged a popular library for QR code scanning (e.g., ZXing or ML Kit's Barcode Scanning API). The critical part here is parsing the otpauth:// URI, which typically looks something like this:
otpauth://totp/Example:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=Example&digits=6&period=30
From this, the app extracts the secret parameter, which is our vital shared key.

2. Secure Secret Key Storage

Storing the secret key directly in plain text is a huge security risk. For this project, I opted for Android's EncryptedSharedPreferences (from the AndroidX Security library), which stores data securely using the Android Keystore system. This encrypts the secret key at rest.

3. TOTP Generation Logic

This is where the core algorithm comes into play. I implemented the TOTP algorithm using a standard Java cryptography library (or a custom implementation if you prefer to go deeper).

The generateTOTP function typically takes:

secretKey (the base32 decoded secret)

time (current Unix timestamp divided by the time step, e.g., 30 seconds)

digits (number of digits for the OTP, usually 6 or 8)

The algorithm involves:

HMAC-SHA1 Calculation: Computing an HMAC-SHA1 hash using the secret key as the HMAC key and the current time step as the message.
Dynamic Truncation: Taking a specific byte from the HMAC result and using it to dynamically select a 4-byte sequence.
Modulo Operation: Converting this 4-byte sequence into an integer and taking its modulo by 10^digits to get the final OTP.

To make the app dynamic, I used a Handler or a Flow/LiveData to periodically trigger the TOTP calculation and update the UI every second, visually showing the 30-second countdown before a new code appears.

Building A Real-Time Communication System Using Go and WebSocket

H.M.Ashis Rahman — Fri, 10 Oct 2025 19:18:18 +0000

Real-time applications like chat systems, dashboards, or multiplayer games rely on persistent, low-latency communication between client and server. Traditional HTTP is request-response only, but it can’t push data to the client unless the client keeps polling. That’s where WebSockets come in.

In this article, we’ll explore how** WebSockets** work, how connections are established and managed in Go using the Gorilla WebSocket library, and how to safely handle multiple concurrent clients with Go’s concurrency primitives.

We’ll build on a simple Go project using only the standard net/http router and Gorilla WebSocket.

What is a WebSocket?

A WebSocket is a full-duplex communication channel over a single TCP connection. Once established, both client and server can send messages to each other anytime without re-establishing the connection.

Unlike HTTP:

WebSockets stay open until one side closes it.
Communication happens through lightweight frames, not HTTP requests.
Data can flow in both directions independently.

How a WebSocket Connection is Formed?
The WebSocket handshake starts as a standard HTTP GET request with an Upgrade header:

GET /ws HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade

If the server accepts it, it responds with a 101 Switching Protocols status, upgrading the connection to WebSocket. From that point, the connection is no longer HTTP, it’s a persistent socket.

In Go, this upgrade is handled by Gorilla’s Upgrader:

var upgrader = websocket.Upgrader{
    ReadBufferSize:  1024,
    WriteBufferSize: 1024,
    CheckOrigin:     func(r *http.Request) bool { return true },
}

The CheckOrigin function lets us control which clients can connect. Setting it to always return true allows all origins, good for development, not for production.

Connection Establishment and Storage

When a client connects to /ws, the handler upgrades the request:

conn, err := upgrader.Upgrade(w, r, nil)
if err != nil {
    log.Println("Upgrade error:", err)
    return
}

Once upgraded, conn is a *websocket.Conn, which represents an open connection to a client.
We store each connection in memory along with the client’s username (sent in the request header):

mu.Lock()
Connections = append(Connections, map[string]*websocket.Conn{username: conn})
mu.Unlock()

We use a global slice of maps to keep track of all connected users.
A sync.Mutex ensures that concurrent reads and writes to the Connections slice are thread-safe, since multiple clients can connect or disconnect at the same time.

Reading and Writing Messages

After establishing the connection, the server starts listening for messages:

for {
    messageType, msg, err := conn.ReadMessage()
    if err != nil {
        log.Printf("[%s] read error: %v", username, err)
        break
    }

    log.Printf("[%s] says: %s", username, msg)

    resp := fmt.Sprintf("Response to %s: %s", username, msg)
    conn.WriteMessage(messageType, []byte(resp))
}

ReadMessage() blocks until a new message arrives. When it does, it returns the message type, the payload, and any error.

The messageType is important because WebSockets can carry different kinds of messages.

WebSocket Message Types

TextMessage (1): UTF-8 encoded text.
BinaryMessage (2): Arbitrary binary data.
PingMessage (9): Sent by one peer to check if the connection is alive.
PongMessage (10): Sent automatically in response to a ping.
CloseMessage (8): Sent when either side wants to terminate the connection. Most applications only use text and binary frames, but ping/pong frames are crucial for keeping the connection healthy.

Detecting and Closing Idle Connections

In a real-world system, we don’t want idle connections hanging around forever.
We can use SetReadDeadline() to close connections that haven’t received messages for a specific time:

const idleTimeout = 60 * time.Second
conn.SetReadDeadline(time.Now().Add(idleTimeout))
conn.SetPongHandler(func(string) error {
    conn.SetReadDeadline(time.Now().Add(idleTimeout))
    return nil
})

This means:

The server expects a message or pong frame every 60 seconds.
Each time one arrives, the deadline resets.
If the timer expires without activity, ReadMessage() returns a timeout error, and we close the connection.
This is how we automatically disconnect idle clients while keeping active ones alive.

Cleaning Up Disconnected Clients

When a connection closes, we must remove it from our global store to prevent memory leaks:

func removeConnection(username string) {
    mu.Lock()
    defer mu.Unlock()

    var updated []map[string]*websocket.Conn
    for _, m := range Connections {
        if _, ok := m[username]; !ok {
            updated = append(updated, m)
        }
    }
    Connections = updated
}

This ensures that only active connections remain in memory.

Sending Messages to Specific Clients

Sometimes, you need to send data to a particular user. We can look up the connection by username and send directly:

func SendMessageToSpecificUser(w http.ResponseWriter, r *http.Request) {
    body, _ := io.ReadAll(r.Body)
    targetUser := string(body)

    mu.Lock()
    defer mu.Unlock()

    for _, item := range Connections {
        for username, conn := range item {
            if username == targetUser {
                conn.WriteMessage(websocket.TextMessage, []byte("hi "+username))
                log.Printf("Sent message to %s", username)
                w.Write([]byte("sent"))
                return
            }
        }
    }
    w.Write([]byte("user not found"))

This can easily be extended to support broadcasting messages to all clients or to a subset (like chat rooms).

Concurrency and Multithreading in WebSocket Handling

Each HTTP request in Go runs in its own goroutine.
That means every WebSocket connection gets a dedicated goroutine when the handler runs:
mux.HandleFunc("/ws", handlers.WebsocketHandler)

Inside that goroutine:
The for loop reading messages is blocking, but isolated to that connection.
sync.Mutex ensures shared data structures (like Connections) remain safe when multiple goroutines modify them simultaneously.
The Go scheduler handles concurrency efficiently, thousands of WebSocket connections can run in parallel on a single server.

This concurrency model is what makes Go such a great fit for real-time applications.

Putting It All Together

Let’s walk through building and testing the complete WebSocket setup from scratch.

Project Setup

Create your project:

mkdir websocket-chat-appp
cd websocket-chat-appp
go mod init websocket-chat-appp

Install Gorilla WebSocket:

go get github.com/gorilla/websocket

Project structure:

websocket-chat-app/
│── go.mod
├── main.go
└── handlers/
    └── websocket_handlers.go

main.go

package main

import (
    "log"
    "net/http"
    "websocket-chat-app/handlers"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/ws", handlers.WebsocketHandler)
    mux.HandleFunc("/show", handlers.PrintConnections)
    mux.HandleFunc("POST /send", handlers.SendMessageToSpecificUser)

    log.Printf("Server started on :8080")
    http.ListenAndServe(":8080", mux)
}

handlers/websocket_handlers.go


## package handlers

import (
    "fmt"
    "io"
    "log"
    "net/http"
    "sync"
    "time"

    "github.com/gorilla/websocket"
)

// Global variables to store all active connections
var (
    Connections []map[string]*websocket.Conn
    mu          sync.Mutex
)

var upgrader = websocket.Upgrader{
    ReadBufferSize:  1024,
    WriteBufferSize: 1024,
    CheckOrigin:     func(r *http.Request) bool { return true },
}

// WebsocketHandler handles new WebSocket connections
func WebsocketHandler(w http.ResponseWriter, r *http.Request) {
    username := r.URL.Query().Get("username")
    if username == "" {
        http.Error(w, "username query param required", http.StatusBadRequest)
        return
    }

    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println("Upgrade error:", err)
        return
    }

    mu.Lock()
    Connections = append(Connections, map[string]*websocket.Conn{username: conn})
    mu.Unlock()

    log.Printf("[%s] connected", username)

    go handleConnection(username, conn)
}

// handleConnection reads messages and handles connection lifecycle
func handleConnection(username string, conn *websocket.Conn) {
    defer func() {
        removeConnection(username)
        conn.Close()
        log.Printf("[%s] disconnected", username)
    }()

    const idleTimeout = 60 * time.Second
    conn.SetReadDeadline(time.Now().Add(idleTimeout))
    conn.SetPongHandler(func(string) error {
        conn.SetReadDeadline(time.Now().Add(idleTimeout))
        return nil
    })

    for {
        msgType, msg, err := conn.ReadMessage()
        if err != nil {
            log.Printf("[%s] read error: %v", username, err)
            break
        }

        log.Printf("[%s] says: %s", username, msg)
        resp := fmt.Sprintf("Response to %s: %s", username, msg)
        conn.WriteMessage(msgType, []byte(resp))
    }
}

// removeConnection cleans up disconnected clients
func removeConnection(username string) {
    mu.Lock()
    defer mu.Unlock()

    var updated []map[string]*websocket.Conn
    for _, m := range Connections {
        if _, ok := m[username]; !ok {
            updated = append(updated, m)
        }
    }
    Connections = updated
}

// PrintConnections displays all connected usernames
func PrintConnections(w http.ResponseWriter, _ *http.Request) {
    mu.Lock()
    defer mu.Unlock()

    fmt.Fprintln(w, "Connected users:")
    for _, conn := range Connections {
        for username := range conn {
            fmt.Fprintln(w, "-", username)
        }
    }
}

// SendMessageToSpecificUser sends a message to a specific user
func SendMessageToSpecificUser(w http.ResponseWriter, r *http.Request) {
    body, _ := io.ReadAll(r.Body)
    targetUser := string(body)

    mu.Lock()
    defer mu.Unlock()

    for _, item := range Connections {
        for username, conn := range item {
            if username == targetUser {
                conn.WriteMessage(websocket.TextMessage, []byte("hi "+username))
                log.Printf("Sent message to %s", username)
                w.Write([]byte("sent"))
                return
            }
        }
    }
    w.Write([]byte("user not found"))
}

Running the Server

Start the Go server:

go run main.go

Output:

2025/10/09 22:10:41 Server started on:8080

Testing with Postman

Now, let's see how our app works.
Open Postman, then make a WebSocket connection to localhost:8080/ws. Here I am using passing "ashis" as the username, in the header.

Let's make another WebSocket request. Here I am using "barbie" as the username in the header.

Let's see the connected users using HTTP REST API.

Now I am sending messages from the connection "ashis"

But I'm not sending any messages from "barbie". So the connection is closed.

Now, establish both connections again and send a message to a specific user. I am sending a message to "barbie".

Let's see if barbie received the message or not.

As you can see, barbie received the message successfully.

Summary

Here’s what we covered:

How WebSockets work and how they differ from HTTP
How to establish and upgrade a connection using Gorilla WebSocket
Message types and how to read/write frames
How to detect idle clients using SetReadDeadline and close them cleanly
Storing and managing connections safely with sync.Mutex
Concurrency in Go each WebSocket runs in its own goroutine

From concept to code: Building an algorithm visualizer with React and Next.js.

H.M.Ashis Rahman — Tue, 02 Sep 2025 17:12:28 +0000

I used to find studying algorithms a real struggle. The textbooks were dry, and I just couldn't visualize what was happening with the data. To solve this, I decided to build my own interactive algorithm visualizer. I chose React and Next.js for the project, and it turned out to be one of the best ways I've ever learned.

https://ashisrahman.dev/