You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Memory-hard KDF for hashing API keys at rest (Argon2id) #222
Problem Statement. The current keyHash is described as SHA-256 in spec. SHA-256 of an
API key is fast — exactly what an attacker brute-forcing a leaked hash wants.
Why it matters. Even with a long random key, a stolen keyHash can be reversed by
someone who controls the database.
Technical Context. Existing keyHash column allows arbitrary length. Argon2id
produces a 32-byte hash with a parameter-aware string that can fit.
Expected Outcome. API keys are hashed with argon2id, parameters encoded inside the
hash output so verification doesn't need a config match.
I plan to implement Argon2id as a memory-hard KDF for hashing API keys at rest, following the existing security architecture, adding comprehensive tests, and ensuring the implementation is secure and well documented. Could you please assign this issue to me?
I’m a full-stack software and blockchain engineer with hands-on experience delivering production-ready solutions across frontend, backend, and blockchain systems.
I’d like to take ownership of this issue. I’ve reviewed the requirements and can implement a scalable, maintainable, and well-tested solution that fully satisfies the acceptance criteria.
Ready to start immediately and keep the team updated throughout the process.
Hi, I'd like to take this issue. I'll switch API key hashing to argon2id with m=64 MiB, t=3, p=1, update the guard to verify using PasswordHasher.verify, ensure existing SHA-256 hashes fail verification and force re-auth, and add an e2e test covering that failure case. Please assign it to me, thanks.
Activity
AnnieIj commentedon Jul 15, 2026
Hi! I'd love to work on this issue.
I plan to implement Argon2id as a memory-hard KDF for hashing API keys at rest, following the existing security architecture, adding comprehensive tests, and ensuring the implementation is secure and well documented. Could you please assign this issue to me?
Clement-coder commentedon Jul 20, 2026
Hi,
I’m a full-stack software and blockchain engineer with hands-on experience delivering production-ready solutions across frontend, backend, and blockchain systems.
I’d like to take ownership of this issue. I’ve reviewed the requirements and can implement a scalable, maintainable, and well-tested solution that fully satisfies the acceptance criteria.
Ready to start immediately and keep the team updated throughout the process.
kimanicode commentedon Jul 21, 2026
Hi, I'd like to take this issue. I'll switch API key hashing to argon2id with m=64 MiB, t=3, p=1, update the guard to verify using PasswordHasher.verify, ensure existing SHA-256 hashes fail verification and force re-auth, and add an e2e test covering that failure case. Please assign it to me, thanks.
grantfox-oss commentedon Jul 21, 2026
🦊 GrantFox — @kimanicode has been assigned to this issue as part of the Official Campaign | FWC26 campaign!
Next steps:
Closes #222)Good luck! Track your progress on GrantFox.
grantfox-oss commentedon Jul 22, 2026
🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!
@kimanicode's PR #408 was approved and merged by @kilodesodiq-arch.
🏆 @kimanicode: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (449 total points). Track your full progress on GrantFox.
👏 Great work, @kimanicode! Keep contributing to ChainForgee.