DEV Community: Nesniv Ogem

How to Implement Argon2 for Secure Password Hashing in Go

Nesniv Ogem — Tue, 03 Jun 2025 05:05:40 +0000

Table of Content

Understanding Argon2
- Major Benefits from Legacy Algorithms
- Argon2 Variants
Implementation Framework
- Environment Setup
- Cryptographically Secure Salt
- Parameters Configuration
Production Implementation
- Password Hashing Implementation
- Password Verification Implementation
- Testing the Implementation
- Validation Needed
Best Practices and Security Considerations
- Guidelines for Security in Implementation
- Best Practices
Conclusion
- Additional Resources

Understanding Argon2

Being the winner in the Password Hashing Competition (PHC) for its better resistance to current attack vectors, Argon2 is the present gold standard for password hashing methods. Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich created it in reaction to the changing threat environment for password security. The algorithm tackles basic flaws found in outdated hashing algorithms using creative design concepts that give memory-hardness and resistance to specialized hardware attacks.

This article provides best practices, security concerns, and practical implementations for implementing Argon2, especially in Go projects.

Major Benefits From Legacy Algorithms

Argon2 provides advancements above classical password hashing techniques like PBKDF2 and bcrypt:

Memory-Hardness: The main benefit of Argon2 is its high memory usage for hashing process. This trait makes large-scale attacks using specialized hardware (GPUs, ASICs) financially expensive since attackers have to supply considerable memory resources for parallel processing.
Customizable Settings: Depending on their particular infrastructure capabilities, the algorithm offers thorough control over security parameters, therefore enabling companies to balance security needs with performance limits.
Multi-Vector Attack Resistance: Argon2 is meant to resist several attack methods used by threat agents, including brute-force assaults, side-channel attacks, time-memory trade-offs, and more complex techniques.

Argon2 Variants

Argon2 comes in three different versions, each tailored for certain security needs:

Argon2d. Using data-dependent memory access designs, this variant optimized for maximum resistance against GPU-based attacks. This variant introduces computational dependencies that greatly prevent attempts at parallelization. But the data-dependent approach opens possible vulnerability to side-channel timing attacks. Best for controlled environment when side-channel attacks are not a concern (e.g: server password storage).
Argon2i. Using data-independent memory access designs, this variant put priority to avoid side-channel attack, but it is less resistant to GPU attack than Argon2d. This variant offers better defence against timing-based side-channel exploitations. Best for environment where possible attackers might see the hashing process (e.g: cryptocurrencies).
Argon2id. Hybrid method drawing on the best features of either version. First passes using Argon2i aim to avoid side-channel attacks; then change to Argon2d for improved GPU attack resistance. Most production environments are advised to use this variant as it offers balanced defense against many attack vectors.

Implementation Framework

Environment Setup

For Go, the recommended approach is utilizes the official extended cryptography library:

go get golang.org/x/crypto/argon2

This library offers a strong, well managed implementation, following cryptographic best practices.

Cryptographically Secure Salt

A crucial security feature that has to be properly applied is salt generation. Every password has to use a distinct, cryptographically safe salt to avoid rainbow table attacks and guarantee hash uniqueness even for same passwords.

Best Practices:

Choose cryptographically safe random number generators, as in crypto/rand.
Apply 16-byte (128-bit) minimum salt length.
Create distinct salts for every password process.
Don't use pseudorandom generators inappropriate for cryptographic (e.g., math/rand).

Parameters Configuration

Appropriate parameters value are critical for a balance of optimal security and performance. Important parameters needs detailed attention are:

Hash Length: The output hash size in bytes. Longer hashes offer more resistance to collisions. Most applications should use 32 bytes (256 bits); standard implementations range from 16 to 64 bytes.
Memory Cost: The memory usage in KiB (1024-byte units). Higher values improve security but increase resource usage. Typical enterprise setups span 32 MiB (32,768 KiB) to 1 GiB (1,048,576 KiB).
Time Cost: The iteration count. More iterations improve security but increase processing time. Standard practice use 1 to 10 iterations.
Parallelism The concurrent thread usage. Should usually based on the CPU core count on hand. 1, 2, 4, or 8 threads are typical configurations.

Tips: Aim for 250–500 millisecond hashing timing to balance user experience factors with security needs.

Production Implementation

Password Hashing Implementation

Argon2 typically follow the PHC String Format:

$argon2<variant>$v=<version>$m=<memory>,t=<iterations>,p=<parallelism>$<salt>$<hash>

Example:$argon2id$v=19$m=65536,t=3,p=4$G8NYSxrA+UMGHJbZVIXXXQ$UrHyBcYfCEms+92QVzGmfYqrWtH54WJY9FuROBQi/X8

Format Components:

argon2id: Algorithm variant identifier
v=19: Argon2 version
m=65536,t=3,p=4: Parameter encoding (memory, time, parallelism)
G8NYSxrA+UMGHJbZVIXXXQ: Base64-encoded salt
UrHyBcYfCEms+92QVzGmfYqrWtH54WJY9FuROBQi/X8: Base64-encoded hash

package main

import (
    "crypto/rand"
    "encoding/base64"
    "fmt"
    "golang.org/x/crypto/argon2"
    "log"
)

type Argon2Configuration struct {
    HashRaw    []byte
    Salt       []byte
    TimeCost   uint32
    MemoryCost uint32
    Threads    uint8
    KeyLength  uint32
}

func generateCryptographicSalt(saltSize uint32) ([]byte, error) {
    salt := make([]byte, saltSize)
    _, err := rand.Read(salt)
    if err != nil {
        return nil, fmt.Errorf("salt generation failed: %w", err)
    }
    return salt, nil
}

func hashPasswordSecure(password string) (string, error) {
    config := &Argon2Configuration{
        TimeCost:   2,          
        MemoryCost: 64 * 1024,
        Threads:    4,
        KeyLength:  32,
    }

    salt, err := generateCryptographicSalt(16)
    if err != nil {
        return "", fmt.Errorf("password hashing failed: %w", err)
    }
    config.Salt = salt

    // Execute Argon2id hashing algorithm
    config.HashRaw = argon2.IDKey(
        []byte(password),
        config.Salt,
        config.TimeCost,
        config.MemoryCost,
        config.Threads,
        config.KeyLength,
    )

    // Generate standardized hash format
    encodedHash := fmt.Sprintf(
        "$argon2id$v=%d$m=%d,t=%d,p=%d$%s$%s",
        argon2.Version,
        config.MemoryCost,
        config.TimeCost,
        config.Threads,
        base64.RawStdEncoding.EncodeToString(config.Salt),
        base64.RawStdEncoding.EncodeToString(config.HashRaw),
    )

    return encodedHash, nil
}

func main() {
    hash, err := hashPasswordSecure("enterprise_secure_password")
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println("Secure hash generated:", hash)
}

Password Verification Implementation

Password verification need to be well implementated to maintain security, while providing reliable authentication.

package main

import (
    "crypto/subtle"
    "encoding/base64"
    "errors"
    "fmt"
    "golang.org/x/crypto/argon2"
    "strings"
)

func parseArgon2Hash(encodedHash string) (*Argon2Configuration, error) {
    components := strings.Split(encodedHash, "$")
    if len(components) != 6 {
        return nil, errors.New("invalid hash format structure")
    }

    // Validate algorithm identifier
    if !strings.HasPrefix(components[1], "argon2id") {
        return nil, errors.New("unsupported algorithm variant")
    }

    // Extract version information
    var version int
    fmt.Sscanf(components[2], "v=%d", &version)

    // Parse configuration parameters
    config := &Argon2Configuration{}
    fmt.Sscanf(components[3], "m=%d,t=%d,p=%d", 
        &config.MemoryCost, &config.TimeCost, &config.Threads)

    // Decode salt component
    salt, err := base64.RawStdEncoding.DecodeString(components[4])
    if err != nil {
        return nil, fmt.Errorf("salt decoding failed: %w", err)
    }
    config.Salt = salt

    // Decode hash component
    hash, err := base64.RawStdEncoding.DecodeString(components[5])
    if err != nil {
        return nil, fmt.Errorf("hash decoding failed: %w", err)
    }
    config.HashRaw = hash
    config.KeyLength = uint32(len(hash))

    return config, nil
}

func verifyPasswordSecure(storedHash, providedPassword string) (bool, error) {
    // Parse stored hash parameters
    config, err := parseArgon2Hash(storedHash)
    if err != nil {
        return false, fmt.Errorf("hash parsing failed: %w", err)
    }

    // Generate hash using identical parameters
    computedHash := argon2.IDKey(
        []byte(providedPassword),
        config.Salt,
        config.TimeCost,
        config.MemoryCost,
        config.Threads,
        config.KeyLength,
    )

    // Perform constant-time comparison to prevent timing attacks
    match := subtle.ConstantTimeCompare(config.HashRaw, computedHash) == 1
    return match, nil
}

func authenticateUser(storedHash, password string) error {
    isValid, err := verifyPasswordSecure(storedHash, password)
    if err != nil {
        return fmt.Errorf("authentication process failed: %w", err)
    }

    if !isValid {
        return errors.New("authentication credentials invalid")
    }

    return nil
}

Testing the Implementation

Validation of cryptographic implementations depends on thorough testing.

package main_test

import (
    "bytes"
    "testing"

    "golang.org/x/crypto/argon2"
)

func TestArgon2Consistency(t *testing.T) {
    password := []byte("enterprise_test_password")
    salt := []byte("standardized_salt_value")

    // Standard parameters
    timeCost := uint32(3)
    memoryCost := uint32(64 * 1024)
    threads := uint8(4)
    keyLength := uint32(32)

    // Generate multiple hashes with identical parameters
    hash1 := argon2.IDKey(password, salt, timeCost, memoryCost, threads, keyLength)
    hash2 := argon2.IDKey(password, salt, timeCost, memoryCost, threads, keyLength)

    // Verify consistency
    if !bytes.Equal(hash1, hash2) {
        t.Error("Identical inputs produced inconsistent hashes")
    }

    // Verify uniqueness for different inputs
    differentPassword := []byte("alternative_test_password")
    hash3 := argon2.IDKey(differentPassword, salt, timeCost, memoryCost, threads, keyLength)

    if bytes.Equal(hash1, hash3) {
        t.Error("Different passwords produced identical hashes")
    }
}

func TestArgon2EdgeCases(t *testing.T) {
    salt := []byte("edge_case_testing_salt")
    timeCost := uint32(1)
    memoryCost := uint32(32 * 1024)
    threads := uint8(2)
    keyLength := uint32(32)

    // Test empty password handling
    emptyPassword := []byte("")
    hash := argon2.IDKey(emptyPassword, salt, timeCost, memoryCost, threads, keyLength)
    if len(hash) != int(keyLength) {
        t.Error("Empty password handling failed")
    }

    // Test extended and special characters handling
    extendedPassword := append(bytes.Repeat([]byte("x"), 1000), []byte("🙂🙃")...)
    hash = argon2.IDKey(extendedPassword, salt, timeCost, memoryCost, threads, keyLength)
    if len(hash) != int(keyLength) {
        t.Error("Extended password handling failed")
    }

    // Verify parameter sensitivity
    baseHash := argon2.IDKey([]byte("test_password"), salt, timeCost, memoryCost, threads, keyLength)
    modifiedHash := argon2.IDKey([]byte("test_password"), salt, timeCost+1, memoryCost+1, threads+1, keyLength)

    if bytes.Equal(baseHash, modifiedHash) {
        t.Error("Parameter modification did not affect hash output")
    }
}

Validation Needed

Consistency Testing. Check that the same inputs yield consistent results throughout several runs. Validate that various inputs produce different hash values.
Parameter Sensitivity. Guarantee that changes in parameters produce distinct hash outputs.
Edge Case Handling. Test limits with special character sets, maximum-length passwords, and zero passwords.
Standard Compliance. Validate against Argon2 official test vectors to guarantee specification compliance.

Best Practices and Security Considerations

Error Handling. Maintaining security also need to do correct error handling and gives suitable system feedback. Present generic authentication failure message e.g: Login Failed to users, it will help to avoid information leak. But log detailed technical errors for further issue analysis.

Use the encoded hash format. Avoid storing the parameters separately. The encoded hash string contains all needed data for password verification.

Benchmark on production hardware. Performance tuning has to be done in your real production setting. Parameters that work well on development computers might be unsuitable or ineffective in production.

Periodically parameter revision. Memory and time expenses should be modified as computing capability grows. When handling password verification is a good chance to modifie your hash parameters. You can simply re-hash the valid plain passwords with the new parameters.

Limit a sensible maximum password length. Unlike 72 bytes limit on bcrypt, Argon2 practically allows unlimited length of input. But permitting very long passwords could leave the system open to denial-of-service attacks. It's best to limit the password to a sensible length, usually 64 to 128 characters.

Utilize reliable libraries. Instead of implementing Argon2 by your own from scratch, depend on well-known, highly vetted libraries.

Test your implementation. Test against recognized input-output pairs to guarantee the robustness of your setup. Verify that invalid credentials are consistently rejected and that valid ones are authenticated properly. You can compare your implementation with available online generator or validator tools.

Conclusion

Providing strong defense against modern assault techniques, Argon2 is the current state-of-the-art in password hashing technology. Good execution calls for close focus on parameter configuration, coded language, and continuous security upkeep.

Argon2 should be used by companies giving top priority thorough testing, constant parameter review, and compliance with known cryptographic best practices. Good implementation investments offer substantial security advantages and show dedication to safeguarding user credentials against changing threat environments.

Additional Resources

[Boost]

Nesniv Ogem — Tue, 22 Apr 2025 11:38:40 +0000

Nesniv Ogem

Apr 5 '25

Understanding Bcrypt's Work Factor and Choosing the Right Value

#programming #security #webdev #go

Comments

5 min read

Understanding Bcrypt's Work Factor and Choosing the Right Value

Nesniv Ogem — Sat, 05 Apr 2025 16:39:18 +0000

My Thought on Bcrypt & Why Work Factor Matters

If you ever work with passwords in coding either for work or for fun, you probably know the #1 rule: never store them as plain text! I’ve always seen bcrypt as the go-to for password hashing. Developers seem to love it. But let’s be honest, a lot of us just copy-paste some code from the Stack Overflow without really thinking about what’s going on under the hood. And in doing so, we often skip an important detail: the work factor.

What so special about bcrypt?

Bcrypt not just another hashing function, it has two key features that make it stand out:

Automatic salt. Every time you hash a password, it generates and use a unique salt. This basically shuts the door on rainbow table attacks.
Adaptive hashing (a.k.a. slowing things down on purpose). You can tweak a parameter called the work factor, which makes hashing take longer time and more computation power. This is actually a good thing! It means brute-force attacks become much harder and way more expensive.

At first, I thought the work factor was just some random number you set once and forget. Nope. Turns out, it’s crucial for keeping passwords secure, and you need to adjust it as computers get faster.

Why Work Factor Matters

Hardware technology move fast, and what was "secure" ten years ago might be considered weak today. Here’s a rough timeline:

2010: Work factor 10 was considered solid.
2025: Security pros suggest bumping it up to 12 or 14.
Future: We might need 15+ as hardware keeps improving.

Basically, if your work factor is too low, bcrypt won’t be as effective. And if it’s too high, well… your users might start thinking your app is broken.

What I want to share

What the work factor actually does.
How to pick the right number for your project.
Some tricks to keep your passwords safe without making your project slow.

So whether you’re just starting with bcrypt or fixing an old project, getting the work factor right is what takes your password security from “eh, good enough” to “actually solid”.

So, What is Work Factor?

Basically, work factor (also called cost or rounds) is a parameter that controls how much computation being done to hash a password. More computation means more secure, but also more processing time and resource.

It grows exponentially, every time the work factor increased by 1, the hashing takes around twice as long. Under the hood Bcrypt repurposes the Blowfish cipher by using an expensive key setup mechanism, where the password is used during the key schedule. This work factor parameter controls the number of key setup iterations as 2^work_factor. This process is CPU intensive, unlike memory intensive algorithms like Argon2.

So what does it mean in practice? Because a small increase can make hashing time jump exponentially, you can adjust this parameter based on your security requirement, or today hardware capability, making it harder to be brute forced regardless of advancement in hardware capability.

A quick benchmark with Go in MacBook Air Apple M2 to show how hashing time doubles on each increase of the work factor:

package main

import (
    "fmt"
    "time"

    "golang.org/x/crypto/bcrypt"
)

func benchmarkBcrypt(workFactor int) {
    start := time.Now()
    password := []byte("mySecurePassword123")

    hash, err := bcrypt.GenerateFromPassword(password, workFactor)
    if err != nil {
        panic(err)
    }

    fmt.Printf("Work factor %d: %v (Hash: %s...)\n", workFactor, time.Since(start), string(hash)[:20])
}

func main() {
    for workFactor := 8; workFactor <= 18; workFactor++ {
        benchmarkBcrypt(workFactor)
    }
}

Output:

Work factor 8: 17.70425ms (Hash: $2a$08$E.o7Tqw8T07rh...)
Work factor 9: 36.118125ms (Hash: $2a$09$JIS9lqNj47THu...)
Work factor 10: 72.501958ms (Hash: $2a$10$axDX0ijlIs3p....)
Work factor 11: 143.923834ms (Hash: $2a$11$m2KDuQl30gz6I...)
Work factor 12: 284.81625ms (Hash: $2a$12$n.fKAp6jHNJWw...)
Work factor 13: 573.204375ms (Hash: $2a$13$AQIMEUfJvtrQB...)
Work factor 14: 1.151081s (Hash: $2a$14$EewXxPOg0JPnl...)
Work factor 15: 2.300344583s (Hash: $2a$15$TAtTjpNYsTO0V...)
Work factor 16: 4.658600542s (Hash: $2a$16$luaozYqMW1kME...)
Work factor 17: 9.3284315s (Hash: $2a$17$U.OuLzA1HwqhQ...)
Work factor 18: 18.565636625s (Hash: $2a$18$h8rxVyo2fUK2W...)

NOTE: The computation time is nearly identical for both generating and comparing/verifying the hash.

If you’re using bcrypt, you need to check in on your work factor every few years. As computers get stronger, what’s "secure" today might be considered tomorrow.

What Work Factor Should I Use?

Bcrypt still relevant because it’s slow on purpose, but how slow is too slow?
As always the answer is "it depends". What kind of app are you building? How strong is the hardware? How much patience do your users have?

In general, it's recommended to determine it by the amount of time password verification will take on your server, then calculate the value of work factor based upon that. You want verification to take as long as you can stand.

In general, it's recommended to keep it under 1 second:

Too Low (≤10): Easy pickings for modern GPUs and cloud brute-force attacks.
Sweet Spot (12-14): Good mix of security and speed (~250ms–1s per hash).
Too High (≥16): Feels like your app is crawling, and your server might cry.

Rough guide based on project type on this article written(2025):

Application Type	Minimum Value	Notes
Development/Testing	10	Fast, but not recommended for production!
General Web Apps	12	Secure enough without slowing things down (300-500ms)
Financial/Healthcare	13-14	Stronger protection, but adds ~1-2s per login
Password Managers	14+	Hardcore security for stored passwords

Things to consider:

Will users notice? Most won’t care if login takes 1 second. (They’ll survive.)
Can your servers handle it? Higher work factors mean higher CPU load.

Future-Proofing Your Password Hashing

One key advantage of having a work factor is that it can be increased over time as hardware becomes more powerful and cheaper. Common approach to upgrading the work factor is to gradually upgrade hashes until the next user authenticates, then re-hash their password with the new work factor. Depending on the requirement, it might be needed to force logout the users e.g: invalidate their session cookie or rolling your JWT secrets, to trigger the authentication flow.

Keep it adjustable. It's better to not hardcode your work factor, instead, store it in your configuration system.

func Authenticate(ctx context.Context, email, password string) (bool, error) {
    user := db.GetUserByEmail(email)

    err := bcrypt.CompareHashAndPassword(user.PasswordHash, []byte(password))
    if err != nil {
        return false, err
    }

    currentCost, _ := bcrypt.Cost(user.PasswordHash)
    if currentCost < config.MinWorkFactor {
        newHash, _ := bcrypt.GenerateFromPassword(
            []byte(password), config.MinWorkFactor)
        db.UpdateUserPassword(user.ID, newHash)
    }

    return true, nil
}

Benefits:

✔ No user interruption
✔ Self-healing system over time
✔ Distributed computational load

Key Takeaways for Implementers

Each +1 doubles hashing time and brute-force resistance. 12 is the new minimum in 2025.
Migration is inevitable. Hardware advances require periodic work factor bumps. Rolling rehashes beat mass password resets.
Context Matters. Financial apps need 14+ while IoT may cap at 8-10. Monitor and adjust based on your threat model.

Reference and tools that might be useful for you: