Generate custom PBKDF2 password hash

[MichaIng]

Hey guys,

we like to generate and apply a custom PBKDF2 password hash via shell script for the web interface, before starting up qBittorrent the first time. With MD5 this was easy, but I fail to generate a correctly interpreted PBKDF2 hash. I tried it with openssl enc and openssl passwd, but while the first supports PBKDF2, it doesn't seem to really hash a password when no encryption via another password is done. And the second supports sha512 but no PBKDF2, it seems.

Does anyone have an idea?

Best regards

[userdocs]

They do it here

https://github.com/swizzin/swizzin/blob/master/scripts/qbittorrent.Userpass.py

https://github.com/swizzin/swizzin/blob/master/sources/functions/qbittorrent#L397-L398

[MichaIng]

One benefit of using the qBittorrent API is that it will likely work reliably for a longer time while any custom method breaks as fast as algorithm parameters change. But indeed it has the large downside that the qBittorrent server needs to run already. A command line option to apply it "offline" to a given config file would be best, so that it remains a working method also when the hash algorithm or its parameters change in the future.

Okay I think that's the two options currently (API and Python), both not ideal but at least something. I'll keep the question up for a while in the hope that someone has/finds another option.

[userdocs]

An offline version to bootstrap the deployment would be helpful but since they hardcode the default I don't think this is would be a priority to implement.

The other alternative is to not use qbittorrent for auth at all and sit it behind Authelia. This is what i do now anyway as Authelia can generate their password via command line.

https://www.authelia.com/docs/configuration/authentication/file.html

[MichaIng]

Yeah of course any proxy or webserver would allow such, but again, we cannot assume such being available or wanted. We're providing a slim simple setup with least possible overhead, also to be compatible with any such additional environments, embedded systems etc. So installing a proxy is not an option, having Python as dependency in worst case yes, but whether to use Python or the API (with localhost bound running qBittorrent) or keep a default password (though a different one than the hardcoded one) needs to be discussed our end.

[userdocs]

Just out of curiosity what exactly is the end goal here?

You only need to set a unique password for deployment in a multi user environment otherwise the responsibility general falls on the end user to configure their deployment. Why do you need to handle this particular deployment configuration?

Who is the target audience for this as most NAS/server systems already have accessible methods for doing this via scripted or dockerised solutions already.

[MichaIng]

Who is the target audience for this as most NAS/server systems already have accessible methods for doing this via scripted or dockerised solutions already.

We're providing such a scripted solution to setup a slim ready-to-run qBittorrent server, where users are/were able to pre-configure the password via dedicated config file. Exactly that got broken with the switch to PBKDF2 and the release of Debian Bullseye which ships a qBittorrent version with this change.

Our implementation addresses also low end hardware (Raspberry Pi Zero likes) where running a container or additional software (like a proxy) has significant impact on the system load and remaining capabilities, and we generally like to keep it simple and transparent (one service => one process, where possible). It also addresses users with less Linux experience, so that we cannot (or don't want to) expect the environment to be isolated/save already (e.g. related network port closed/blocked by NAT/firewall, at least until first access and password change) while it shall simply run OOTB and at boot via service daemon, accessible from a remote non-headless system via browser, preferably with a pre-defined non-default password, for security but also convenience reasons.