Rainbow Table Attack in Echo Go

In Echo Go applications, a Rainbow Table Attack becomes feasible when password storage relies on fast, unsalted cryptographic hashes like MD5, SHA-1, or SHA-256. Echo Go itself does not enforce a specific password hashing strategy; it provides authentication middleware (e.g., echo/middleware.BasicAuth or echo/middleware.JWT) but leaves the underlying user credential storage to the developer. A common vulnerable pattern is using Go's standard crypto/md5 or crypto/sha256 packages to hash passwords directly, without a per-user salt and without a computationally expensive work factor.

Consider this typical Echo Go user registration handler that stores an MD5 hash:

package main

import (
    "crypto/md5"
    "encoding/hex"
    "net/http"
    "github.com/labstack/echo/v4"
    "github.com/labstack/echo/v4/middleware"
)

func registerHandler(c echo.Context) error {
    type Credentials struct {
        Username string `json:"username"`
        Password string `json:"password"`
    }
    var creds Credentials
    if err := c.Bind(&creds); err != nil {
        return c.JSON(http.StatusBadRequest, map[string]string{"error": "invalid request"})
    }

    // VULNERABLE: Fast hash, no salt
    hash := md5.Sum([]byte(creds.Password))
    hashedPassword := hex.EncodeToString(hash[:])

    // Store hashedPassword in database (e.g., SQL, MongoDB)
    // ... db.Exec("INSERT INTO users(username, password) VALUES(?, ?)", creds.Username, hashedPassword)

    return c.JSON(http.StatusCreated, map[string]string{"message": "user created"})
}

func main() {
    e := echo.New()
    e.Use(middleware.Logger())
    e.POST("/register", registerHandler)
    e.Logger.Fatal(e.Start(":8080"))
}

The md5.Sum call produces a 128-bit hash in microseconds. An attacker with a precomputed rainbow table (a vast database of common passwords and their MD5 hashes) can instantly reverse the hash to recover the original plaintext password. If the same password is reused across services, the breach escalates. This violates OWASP API Security Top 10 2023: API2:2023 — Broken Authentication and API8:2023 — Security Misconfiguration (insecure default hashing). The vulnerability manifests at the API layer during registration or password update endpoints, where user-supplied secrets are transformed and persisted.

Detecting this issue in an Echo Go API requires analyzing both the OpenAPI specification (if available) and runtime behavior. middleBrick's scanning process tests the unauthenticated attack surface. Its Authentication and Input Validation checks are particularly relevant.

Static Analysis (Spec): If the Echo Go app provides an OpenAPI/Swagger spec (often at /swagger or /openapi.json), middleBrick resolves all $ref and inspects securitySchemes and parameter schemas. It looks for password fields (e.g., password, pwd) and flags if the spec lacks constraints like minLength or format hints that might indicate weak hashing policies. However, the spec rarely reveals the hashing algorithm.

Dynamic Analysis (Runtime): middleBrick's black-box scanner probes the API. For a registration endpoint (POST /api/v1/register), it submits known test passwords (e.g., "password123") and captures the response. It then attempts to infer the hashing algorithm by analyzing the response time and hash format. A sub-millisecond response suggests a fast hash like MD5/SHA-1. If the stored hash is returned in the response (a severe Data Exposure flaw), the scanner directly identifies the hash type by its length (32 hex chars = MD5, 40 = SHA-1, 64 = SHA-256). Even if not returned, the scanner may use a timing side-channel: fast hashes return almost instantly, while bcrypt or Argon2 introduce deliberate delays (hundreds of milliseconds).

To scan your Echo Go API with middleBrick, use the CLI tool for a quick assessment:

middlebrick scan https://your-echo-api.example.com

The resulting report will highlight any Authentication category findings related to weak password hashing, assigning a severity (likely high) and providing the evidence (e.g., "Password hash returned in response uses MD5"). The GitHub Action can gate deployments if such a critical finding appears:

# In .github/workflows/api-security.yml
- name: Scan API with middleBrick
  uses: middlebrick/github-action@v1
  with:
    api_url: ${{ env.STAGING_API_URL }}
    fail_on_risk_score: 70  # Fails if score drops below C (70)

This integrates detection directly into your CI/CD pipeline for Echo Go services.

Remediation in Echo Go involves replacing fast, unsalted hashes with a slow, salted, adaptive password hashing function. The Go ecosystem recommends golang.org/x/crypto/bcrypt or golang.org/x/crypto/argon2. Bcrypt is the most straightforward to integrate into an Echo Go handler and includes salt generation automatically.

Step 1: Add the bcrypt dependency.

go get golang.org/x/crypto/bcrypt

Step 2: Update the registration handler to use bcrypt.GenerateFromPassword.

package main

import (
    "golang.org/x/crypto/bcrypt"
    "net/http"
    "github.com/labstack/echo/v4"
    "github.com/labstack/echo/v4/middleware"
)

func registerHandler(c echo.Context) error {
    type Credentials struct {
        Username string `json:"username"`
        Password string `json:"password"`
    }
    var creds Credentials
    if err := c.Bind(&creds); err != nil {
        return c.JSON(http.StatusBadRequest, map[string]string{"error": "invalid request"})
    }

    // SECURE: bcrypt automatically generates a random salt and applies a work factor (cost)
    // Default cost (10) is a good starting point; increase for high-security apps.
    hashedPassword, err := bcrypt.GenerateFromPassword([]byte(creds.Password), bcrypt.DefaultCost)
    if err != nil {
        return c.JSON(http.StatusInternalServerError, map[string]string{"error": "failed to hash password"})
    }

    // Store hashedPassword (as []byte or hex/base64 string) in database
    // ... db.Exec("INSERT INTO users(username, password) VALUES(?, ?)", creds.Username, hashedPassword)

    return c.JSON(http.StatusCreated, map[string]string{"message": "user created"})
}

Step 3: Update the login handler to compare using bcrypt.CompareHashAndPassword.

func loginHandler(c echo.Context) error {
    type Credentials struct {
        Username string `json:"username"`
        Password string `json:"password"`
    }
    var creds Credentials
    if err := c.Bind(&creds); err != nil {
        return c.JSON(http.StatusBadRequest, map[string]string{"error": "invalid request"})
    }

    var storedHash string
    // ... db.QueryRow("SELECT password FROM users WHERE username = ?", creds.Username).Scan(&storedHash)

    // Compare the submitted password with the stored bcrypt hash
    if err := bcrypt.CompareHashAndPassword([]byte(storedHash), []byte(creds.Password)); err != nil {
        // This also safely handles timing attacks
        return c.JSON(http.StatusUnauthorized, map[string]string{"error": "invalid credentials"})
    }

    // Generate JWT or session token...
    return c.JSON(http.StatusOK, map[string]string{"token": "..."})
}

Key Echo Go Considerations:

• Middleware Integration: If using Echo's middleware.BasicAuth, provide a validator function that uses bcrypt.CompareHashAndPassword against your user store. The middleware itself does not handle hashing.
• Database Storage: Bcrypt produces a 60-character string (e.g., $2a$10$N9qo8uLOickgx2ZMRZoMy.Mr...). Store it in a VARCHAR(60) or TEXT column. Do not truncate.
• Cost Factor: The second argument to GenerateFromPassword is the cost (log2 rounds). bcrypt.DefaultCost is 10. For high-security applications, consider 12 or higher, but test performance on your production hardware. You can rehash on login if the cost is outdated:

// In loginHandler after successful bcrypt.CompareHashAndPassword
if bcrypt.Cost([]byte(storedHash)) < bcrypt.DefaultCost {
    newHash, _ := bcrypt.GenerateFromPassword([]byte(creds.Password), bcrypt.DefaultCost)
    // Update storedHash in database to newHash
}

By implementing these changes, the Echo Go API's password storage becomes resistant to rainbow table attacks. The salt is unique per password, and the computational cost makes precomputation infeasible. middleBrick's subsequent scan should no longer flag the Authentication category for weak hashing, improving the overall security score.