My 5 cents here.
Speaking about
And if I can I’d love to help with encrypted password storage. How (securely) is the password being sent over the web?
I was thinking about doing something more securely, but the SubSonic API, which is also used by Navidrome, got stuck somewhere in the late 2010s and probably will not be developed anymore, so it is required to deliver an auth token from the plain text password. There is a salt added (since v0.6 – new one for every request), and the resulting token is MD5 hashed, so even if the request is intercepted, the bad guy will need to use brute force to deliver the password from it.
Additional improvements here are possible, e.g.
- It is also possible to hash the password on the device side with some device-specific salt and store it on a FS in a reversible hashed form. If this hash is stolen, yes, the bad guy will need to spend some time to find the salt and reverse the hash. Voila, we can remove the scary message about plain text from the app, but.
– All these manipulations make sense assuming that the attacker’s goal is to see the password, while for Navidrome, it is not needed – there is no check on the server side (at least in the current version) that the token has expired or was used before. The bad guy could use the intercepted or stolen token ‘as-is’ without knowing the password.
– If the whole device is available for a bad guy, he will be able to restore the plain password using the same means that the application would use
– I need to check if there is something TPM-like (or rather crypto storage) available, but even if so, because the app needs plain text, having the device in hand, one can also see the plain text.
- Navidrome (and probably SubSonic) can use a better auth mechanism, which means one still uses the same SubSonic auth mechanism (or even no auth) but puts the whole server behind the proxy, which performs authorization with any modern means. Although this would be a significant step forward, in real life, I mostly see people putting everything in the private VPN and calling it a day.
Actually, that part about hashing on the device side is in my to-do list, but not as a security feature (because it is not), but as a part of refactoring, which is, you know, always somewhere around but not the first priority 
Edit: some clarification about on-device hash
Edit2: maybe it makes more sense to store obvuscated password only until reboot. Looks more feasible than inventing TPM where there is no one, and secure enough