Any of them are fine. I don't think cache timing side channels or any of the other fun scrypt trivia (like PBKDF2-induced trivial collisions) are how you're gonna get popped.

If you wanna do Argon2id that's fine too :-)

I guess that's fair - thanks. I'd previously stayed away from scrypt as a password hash because of these attacks (although I've used it a bunch as a KDF for other things) - but on reflection I think you're probably right and if this is the worst issue you have you're doing fairly well overall.

I don't get the rationale for Argon2id. If you don't expect (cache) timing attacks, Argon2d is computationally stronger. If you do, Argon2i is immune. Argon2id is partially immune, so if someone can do timing attacks, they can crack half the algorithm, and need to do the rest the hard way.

What is the rationale behind the assumption that this middle ground is better than straight up Argon2i for general purpose password derivation? I've never seen it explained anywhere.

Not everyone who needs to store a password is in a position to judge if cache timing attacks will never be in their threat model. Sane recommendations for people who would like to just not mess up their password database matter.

I'm assuming you're familiar with the Argon2 RFC sections on Argon2id? I think it goes into quite a bit of detail between the two.

OK, the latest version of the RFC is much better than what I had initially read. Still, I see no discussion of side channel attacks with Argon2id. When they discuss the "best attack", it looks like they're discussing offline attacks that makes no use of timing information.

Assuming timing attacks breaks Argon2d entirely at relatively little cost, the attacker advantage for a 1-pass Argon2id would be twice that of a one-pass Argon2i: about 10. A three pass Argon2i with a third of the memory looks better: about 3. Not that it matters that much, but still.

Or is my threat model of timing attacks (which assumes they could recover whatever they can at little cost) too paranoid?

I think the RFC suggests sufficiently conservative parameters that it doesn't matter much. And, more generally: I don't think Argon2i vs Argon2d vs Argon2id vs scrypt is where people should be racking their brains.

OK, makes sense.