Argon2id

It is a key derivation function, not a general purpose hash function, and the difference is the point: it is deliberately slow and configurable, where a general purpose hash is deliberately fast. Three parameters set the cost. Memory decides how much working memory each guess requires, iterations decide how many passes are made over it, and parallelism decides how many lanes are used. The RFC gives recommended configurations for two profiles, one favouring memory and one favouring time, and those are the numbers to work from rather than any figure quoted second hand.

The id suffix names the variant, and it is the one to choose. Argon2d resists cracking hardware well but accesses memory in a pattern that depends on the secret, which leaks through side channels; Argon2i avoids that leak at some cost to resistance; the hybrid runs one pass of the second and the rest as the first, which is why it is the general recommendation. bcrypt and scrypt are siblings rather than alternatives to be dismissed, and both remain acceptable where a platform supports them and not this.

In an audit what we record is the function, its parameters and whether they have been raised since the system was built, because costs chosen years ago are now cheap. Two practical notes: the parameters are stored in the output string, so raising them means rehashing at next login rather than running a migration, and memory cost is a capacity decision, since concurrent logins multiply it.