Rainbow Table Attack in Chi with Basic Auth

A Rainbow Table Attack leverages precomputed hash chains to reverse cryptographic hashes quickly. When an API uses HTTP Basic Auth over an unencrypted channel in Chi, the base64-encoded credentials transmitted in the Authorization header are easily intercepted. Although Basic Auth itself does not store passwords as hashes on the server, the intercepted base64 string can be decoded to reveal plaintext credentials. If the service stores or logs credentials as unsalted MD5 or SHA-1 hashes, an attacker who gains access to those hashes can use a Rainbow Table to map them back to plaintext passwords. This is particularly risky in environments where password policies are weak, leading to predictable passwords that appear in common Rainbow Tables. In Chi, misconfigured logging or monitoring may inadvertently persist these hashes, enabling offline attacks even when transport-layer protections are assumed. The combination of predictable password choices and insufficient hashing practices amplifies the exposure window, allowing attackers to reconstruct credentials without needing live traffic interception beyond initial capture.

For example, an intercepted header Authorization: Basic dXNlcjpwYXNz decodes to user:pass. If the backend stores 5f4dcc3b5aa765d61d8327deb882cf99 (MD5 of password), a prebuilt Rainbow Table can reverse it instantly. This illustrates how weak hashing in storage compounds the risk posed by Basic Auth’s clear-text transmission when not protected by TLS. The scanner checks for weak hashing algorithms and missing salting, flagging high-risk patterns in credential handling. These findings align with OWASP API Top 10 authentication flaws and PCI-DSS requirements around secure credential storage.

middleBrick scans identify these issues by correlating runtime behavior with spec-defined authentication schemes. It checks whether the API uses opaque tokens or modern alternatives and flags reliance on Basic Auth without TLS enforcement or strong backend hashing. By cross-referencing OpenAPI definitions with observed traffic, it highlights where weak authentication patterns intersect with storage practices, providing prioritized remediation guidance. This approach helps teams understand the full attack chain rather than treating authentication and storage as isolated concerns.

Remediation focuses on eliminating Basic Auth where possible and strengthening any remaining usage with robust transport and storage protections. The preferred approach is to migrate to token-based authentication such as OAuth 2.0 or API keys with dynamic issuance. When Basic Auth must be supported, enforce TLS 1.2+ end-to-end and avoid storing passwords as reversible or weakly hashed values. Use salted, memory-hard hashing algorithms like bcrypt or Argon2 for any stored credentials. Never log or persist base64-encoded credentials, and ensure middleware strips or anonymizes authorization headers in logs.

Example 1: Enforcing TLS and rejecting cleartext Basic Auth in Chi (pseudo-config)

# Chi application configuration snippet
import TLS

app = new_chi_app()

# Enforce HTTPS and reject non-TLS requests
app = Plug.SSL.ensure_ssl(
  app,
  rewrite_on: [:x_forwarded_proto],
  hsts: true
)

# Basic Auth plug with validation
BasicAuthPlug = Plug.BasicAuth,
  realm: "Secure API",
  verify: fn username, password ->
    # Use constant-time comparison and validate against hashed credentials
    hashed = Repo.get_by(User, username: username).password_hash
    Bcrypt.verify_pass(password, hashed)
  end
)

app = Plug.Router.plug(app, [
  {Plug.EnsureSSL, [rewrite_on: [:x_forwarded_proto], hsts: true]},
  {BasicAuthPlug, [realm: "Secure API"]},
  ...
])

Example 2: Secure credential hashing and verification in Chi

defmodule MyApp.Auth do
  import Bcrypt

  @hasher Bcrypt.hasher_no_context(12)

  def verify_credentials(username, password) do
    user = Repo.one(from u in User, where: u.username == ^username)
    case user do
      %User{password_hash: hash} when Bcrypt.verify_pass(password, hash) -> {:ok, user}
      _ -> {:error, :unauthorized}
    end
  end
end

# Usage in a Chi plug
BasicAuthPlug = Plug.BasicAuth,
  realm: "API",
  verify: &MyApp.Auth.verify_credentials/2
)

Example 3: Migrate to token-based flow (recommended)

# Instead of Basic Auth, use bearer tokens issued after login
app = Plug.Router.plug(app, [
  {Plug.Parsers, parsers: [:json]},
  fn conn, _ ->
    case conn.params do
      %{"username" => u, "password" => p} ->
        if MyApp.Auth.valid_user?(u, p) do
          token = MyApp.Token.issue(user_id: u)
          json(conn, %{token: token})
        else
          send_resp(conn, 401, "Unauthorized")
        end
      _ -> send_resp(conn, 400, "Missing credentials")
    end
  end
])

These examples show how to enforce strong verification and avoid storing or transmitting credentials in clear text. middleBrick can validate that your API definitions and runtime behavior align with these practices, flagging missing TLS, weak hashing, or lingering Basic Auth usage without adequate safeguards.