Rainbow Table Attack in Gin with Basic Auth

A rainbow table attack leverages precomputed tables of hash values to reverse cryptographic hashes quickly. When Basic Auth is used in a Gin application without additional protections, the credentials are typically transmitted as Authorization: Basic base64(username:password). Although the transmission is base64-encoded rather than encrypted, the critical risk arises after decoding. If the server stores or compares passwords using fast, unsalted hashes (e.g., unsalted MD5 or SHA-1), an attacker who gains access to the hash database or intercepts traffic in a man-in-the-middle scenario can use a rainbow table to map common passwords back to their plaintext equivalents. In Gin, if the authentication logic decodes the header and directly compares the hash of the provided password against a stored hash without a salt, the predictable nature of unsalted hashes makes brute-force and rainbow table attacks feasible. The 12 security checks in middleBrick test this by probing authentication mechanisms and input validation, looking for weak password handling and exposed endpoints that do not enforce sufficient entropy or protective measures. Attack patterns such as credential stuffing and password spraying become practical when rainbow tables are applied to poorly protected hashes. middleBrick’s LLM/AI Security checks further ensure that no system prompt leakage or unsafe handling of credentials occurs in any AI-assisted components of the API. Because rainbow tables rely on known hash inputs, the absence of salting and key stretching in Basic Auth implementations directly increases the likelihood of successful credential recovery.

To mitigate rainbow table attacks in Gin with Basic Auth, you must avoid storing or comparing raw hashes and instead use salted, slow key-derivation functions. Below is a concrete, working example using bcrypt to hash and verify passwords securely.

import (
	"net/http"
	"strings"

	"github.com/gin-gonic/gin"
	"golang.org/x/crypto/bcrypt"
)

// HashPassword returns a bcrypt hash for a plain-text password.
func HashPassword(password string) (string, error) {
	bytes, err := bcrypt.GenerateFromPassword([]byte(password), bcrypt.DefaultCost)
	return string(bytes), err
}

// CheckPasswordHash compares a plain-text password against a bcrypt hash.
func CheckPasswordHash(password, hash string) bool {
	return bcrypt.CompareHashAndPassword([]byte(hash), []byte(password)) == nil
}

// Hardcoded user store for example purposes. In production, use a secure database.
var users = map[string]string{
	"alice": "$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy", // bcrypt hash of "password123"
}

func BasicAuthMiddleware() gin.HandlerFunc {
	return func(c *gin.Context) {
		auth := c.GetHeader("Authorization")
		if auth == "" {
			c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "Authorization header required"})
			return
		}

		const prefix = "Basic "
		if !strings.HasPrefix(auth, prefix) {
			c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "Invalid authorization type"})
			return
		}

		payload := auth[len(prefix):]
		decoded, err := base64.StdEncoding.DecodeString(payload)
		if err != nil {
			c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "Invalid authorization header"})
			return
		}

		creds := strings.SplitN(string(decoded), ":", 2)
		if len(creds) != 2 {
			c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "Invalid credentials format"})
			return
		}

		username, password := creds[0], creds[1]
		expectedHash, exists := users[username]
		if !exists || !CheckPasswordHash(password, expectedHash) {
			c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "Invalid credentials"})
			return
		}

		c.Set("username", username)
		c.Next()
	}
}

func HelloHandler(c *gin.Context) {
	username := c.MustGet("username").(string)
	c.JSON(http.StatusOK, gin.H{"message": "Hello " + username})
}

func main() {
	r := gin.Default()
	r.Use(BasicAuthMiddleware())
	r.GET("/hello", HelloHandler)
	r.Run() // listen on 0.0.0.0:8080
}

This approach ensures that even if an attacker obtains the stored hashes, they cannot efficiently use rainbow tables due to the salt and computational cost of bcrypt. middleBrick’s scans can validate that your authentication endpoints do not leak credentials and that proper status codes and headers are used. For broader protection, combine this with HTTPS to prevent on-path interception and consider rate limiting to hinder online guessing attempts. The Pro plan’s continuous monitoring can alert you if any endpoints exhibit authentication weaknesses over time, while the CLI allows you to script checks within your development workflow.