Using Argon2 for Client Authentication

[awgcooper]

I'm running a pretty up-to-date docker image which includes the argon python argon2-cffi module (argon2 and _argon2_cffi_bindings among the folders stored in site-packages). I currently have the following config section in the config file:

[auth]
type = htpasswd
htpasswd_filename = /config/users
htpasswd_encryption = bcrypt

[storage]
filesystem_folder = /data/collections

I'd like to switch to argon2 authentication but am not sure of the right way to generate a compatible hash that will work with htpasswd given it cannot natively create one; or, if this is not possible, what's an alternative approach. Using the standard argon2 output with something like this in the users htpasswd output file doesn't work:
user1:$argon2id$v=19$m=1048576,t=4,p=2$NktFSWJkRCtNSThRZDlPVHZpUnF4QT09$Vz4oYPhdcOl/kzeGwmIGeLYXU+mDWhB+zU+yCrT078s

I also tried truncating the above as follows but no success there either:
user1:$NktFSWJkRCtNSThRZDlPVHZpUnF4QT09$Vz4oYPhdcOl/kzeGwmIGeLYXU+mDWhB+zU+yCrT078s

I hope I'm not missing something embarrassingly obvious. Any suggestions would be welcome.

[pbiering]

have you toggled htpasswd_encryption to autodetect in advance before replacing bcyrpt with argon2 hash for a user?
See also https://github.com/Kozea/Radicale/blob/master/DOCUMENTATION.md#htpasswd_encryption

[awgcooper]

I tried that just now. I had the long form argon2 hash in the users file. I edited the config file to replace bcrypt with autodetect. Reboot. Tried login (it failed). Replace autodetect in config file with argon2, reboot, tried login, it failed. The log did return this message:
ERROR] Login verification failed for user: 'test' (htpasswd/argon2) with error 'malformed argon2 hash'

I was about say it seems the cause of the problem is clear but I switched back to autodetect in the config file and a long form argon2 hash in the users file (I used both 2i and 2id). I wanted to check the logs with this setting and somewhat surprisingly I found this line:
[INFO] auth htpasswd encryption is 'radicale.auth.htpasswd_encryption.autodetect' and argon2 module found (argon2 entries found: 1)

No mention of a malformed argon2 hash.

I tried to login and the browser returned a 502 error which I'm pretty sure I haven't seen before. That strikes me as a bit odd - doesn't that mean the server can't be contacted (the radicale docker image is behind a reverse proxy). I immediately switched backed to bcrypt and autodetect and logged in fine. Just to be complete, I changed to config file again to argon2 and again, there was a 502 error. In fact I can't seem to generate the 'malformed argon2 hash' log error message any more.

Sorry, this is becoming a bit convoluted for what I had hoped would be a simple question.

P.S. I removed the reverse proxy and exposed a port directly to the internet. The same problems as described above reproduced themselves.

[pbiering]

argon2 hashes to test implementation were generated using example

python -c 'from passlib.hash import argon2; print(argon2.using(type="ID").hash("password"))'
$argon2id$v=19$m=65536,t=3,p=4$A8A4h3DundPaew+BUMq5Nw$P59NE0fBTpH/ohkC93NA+2AIp0RSgGJpkTpJqOk2+jM

see also

Radicale/radicale/auth/htpasswd.py

Line 50 in b7779ba

- ARGON2 (python -c 'from passlib.hash import argon2; print(argon2.using(type="ID").hash("password"))')

# Your example
$argon2id$v=19$m=1048576,t=4,p=2$NktFSWJkRCtNSThRZDlPVHZpUnF4QT09$Vz4oYPhdcOl/kzeGwmIGeLYXU+mDWhB+zU+yCrT078s

# From above:
$argon2id$v=19$m=65536,t=3,p=4$A8A4h3DundPaew+BUMq5Nw$P59NE0fBTpH/ohkC93NA+2AIp0RSgGJpkTpJqOk2+jM

The message malformed argon2 hash is forwarded from Python's argon2 module, so Radicale cannot help here.

[awgcooper]

I used the python code you provided to generate the argon2 hash and it works just fine. I then used the bash argon2 utility to generate a hash using the same parameters that are in the hash you created:

echo password | argon2 `head -c 16 /dev/urandom | base64` -t 3 -m 16 -p 4 -l 32 -id

I then swapped this out in the users file with the python created hash that worked and, guess what - yet again this version didn't work. I think we've isolated the cause to the bash utility but I'm not sure if that's important enough to dig any deeper, other than perhaps posting a warning somewhere that one person using 'argon2/stable,now 0~20190702+dfsg-4+b2 amd64' on Debian 13 has had trouble generating correct hashes.

Anyway, thanks a lot for helping me fix this.