"Security is not a product, but a process." — Bruce Schneier
Security is not something you buy once and forget; it is something you keep working on. Fintag handles corporate financial data, and we believe security should never be a negotiable option — it must be the default of the service.
Today we want to share one example of putting that belief into practice. Fintag recently migrated its password protection from bcrypt, the long-standing industry standard, to Argon2id, the algorithm most strongly recommended today. Here is why we made the change, what became safer, and how we pulled it off without users noticing a thing.
1. Fintag does not know your password
First, the premise: a properly built service never stores your password. What it stores is a hash — the result of passing your password through a one-way function.
"MyP@ssw0rd!" → hash function → "$argon2id$..." (irreversible string)
A hash works in one direction only. You can compute a hash from a password, but you cannot recover the password from the hash. When you log in, we simply hash what you typed and compare it with the stored value. Even in the worst case of a database breach, what an attacker obtains is not passwords but a pile of hashes.
The problem is that attackers take that pile and run brute-force attacks — hashing common password candidates one by one until something matches. This is why password hash functions are judged by the opposite standard of normal functions: a good one is deliberately slow and deliberately expensive.
2. bcrypt wasn't wrong. The times changed
Designed in 1999, bcrypt has guarded the industry for more than 25 years, and Fintag used it from the start. To be clear: bcrypt itself has not been "broken."
What changed is the attacker's hardware.
When bcrypt was designed, attackers computed hashes on CPUs. But a bcrypt computation uses only about 4KB of memory, and computations that barely touch memory are easy to parallelize across the thousands of cores in a modern GPU. Since the cryptocurrency mining boom, high-end GPUs have become commodity hardware you can even rent by the hour in the cloud. The cost of attack has fallen to a fraction of what it was 25 years ago.
When attack costs drop while your defense stands still, you raise the defense. Security technology must keep pace not with when it was adopted, but with where attackers are today.
3. Argon2id — a hash that weaponizes memory
Argon2 is the winner of the 2015 Password Hashing Competition (PHC), vetted by cryptographers worldwide. It has since become an IETF standard (RFC 9106) and is the first-choice recommendation in OWASP's password storage guidance.
The core idea is simple and powerful: force the computation to use a large amount of memory (memory-hardness).
- bcrypt: ~4KB of memory per hash → thousands of GPU cores can compute in parallel
- Argon2id: forces thousands of times more memory per hash → the number of concurrent computations on the same GPU collapses, bounded by memory capacity
Raw speed can be bought with parallelism, but handing a large memory budget to every core is far more expensive. The design economically neutralizes the attacker's strongest weapon: massive parallelization.
The id suffix matters too. Argon2 comes in two variants: Argon2d, strong against GPU attacks, and Argon2i, strong against side-channel attacks. Argon2id is a hybrid of both, providing balanced protection against both attack classes — and it is the variant recommended by the RFC and OWASP alike.
Fintag runs Argon2id with parameters tuned for our production environment at or above OWASP's published recommendations.
4. One step further — the pepper
On top of Argon2id, Fintag adds another layer: a pepper.
A salt is a random value unique to each hash, ensuring identical passwords produce different hashes and defeating rainbow-table attacks (built into Argon2id by default). A pepper goes further: it is a secret key known only to the server. Fintag processes each password with HMAC-SHA256 keyed by the pepper before it ever reaches Argon2id.
stored hash = Argon2id( HMAC-SHA256(key = pepper, msg = password) )
The pepper is not stored in the database — it lives in isolated, dedicated secret-management infrastructure. The implication is clear: even if the entire database were leaked, an attacker without the pepper cannot even begin a cracking attempt. What they hold is not a pile of hashes but a locked safe.
5. The migration nobody noticed
When we decided to switch algorithms, the hardest question was operational, not technical: "What do we do with existing bcrypt hashes?"
Hashes cannot be reversed, so the server cannot batch-convert them. Some services force every user to reset their password; we refused to push that inconvenience onto our users. Instead, we implemented progressive rehash-on-login:
Login attempt
├─ Is the stored hash in bcrypt format?
│ └─ Verify with bcrypt → on success, immediately
│ re-store as an Argon2id + pepper hash
└─ Already Argon2id? → verify directly
Users simply log in as usual — and at that moment, their account's protection is silently upgraded to the latest standard. Not a single user reset a password. Not a single second of downtime.
We engineered for operational stability as well. Argon2id intentionally consumes memory, so a burst of simultaneous logins could pressure server memory. Fintag put a queue in front of password operations that caps concurrent hashing, so the security upgrade never threatens service availability. Security and availability are not a trade-off to pick between; they are both things you design for.
6. Closing — security is not up for negotiation
This migration added zero new buttons for our users. The screens are the same; login feels the same. That is what security work looks like: the better it goes, the more it looks like nothing happened.
But behind the scenes, your password is now protected by the method most strongly endorsed by international standards bodies and the security community.
Fintag handles corporate financial data, and we do not treat security as a cost. Security is not up for negotiation — it is the minimum qualification for a financial service to speak of trust. As attackers' tools evolve, so will our defenses, and we will keep sharing that journey as transparently as we did today.
The Fintag engineering blog shares the technical decisions we make while building our service, and the reasoning behind them. Contact: support@fintag.kr
