Deprecating token (MD5) authentication?

[dmdeller]

Last week, @deluan said this on the Navidrome Discord:

Hey @app developers , does your app rely on the token+salt authentication? I'm planning to eventually sunset it, in favour of api-keys or even plain passwords. What would be the impact on your app if I disable token+salt by default (with an option for the user to renable it)?

(link to message)

As I understand it, Navidrome (and presumably, all other servers that implement token auth) must keep the password in clear text in the database, in order to implement token authentication. Because of the random salt, the only way to validate the password is to start from the same clear text and run the same hash+salt on the server side. (Or, theoretically, you could try to crack the MD5 on every HTTP request, but that would be a bit impractical, to say the least.)

Anyway, it's not good practice to keep a cleartext copy of the password anywhere in storage, so I see why they would want to move away from that. Some related bug reports: [1] [2]

But in doing so, Navidrome will no longer be able to support token auth.

The OpenSubsonic spec currently says this:

Starting with API version 1.13.0, the recommended authentication scheme is to send an authentication token, calculated as a one-way salted hash of the password.

This text seems to have been copied directly from the Subsonic API docs.

So in other words, the spec is currently recommending the same thing that Navidrome wants to stop doing.

As a result, some clients (including mine) were under the mistaken impression that we could implement only token authentication and conform to the OpenSubsonic spec that way. It's reasonable to read that part of the spec and come away with the understanding that all OpenSubsonic servers support token auth; but it seems like this may not be the case in the future.

I have now fixed this in my client, so that it falls back to hexadecimal or plaintext passwords when it encounters error code 41 or 42.

I'm thinking we should probably make some changes to this page in the spec so that new clients reading the spec will better understand what they need to do.

I can write up a PR for this change, but before I do that, I wanted to open this up for discussion first. Any thoughts or concerns?

[Tolriq]

We can't really change the OG specs.

What LMS does is that it enforce passing the apiKeys to auth to the legacy endpoints. That's a nice middle ground.

[paulijar]

Then on the other hand, if the malicious user can see the user's t+s from the logs, then he can just use those to use any Subsonic endpoints. I would guess that no server prevents the reuse of the same salt (as it would be hugely inconvenient). So the only added security from t+s is for the cases where the user reuses the same password on multiple services; then finding the plain text password could allow the attacker to log into some other services, too. This is not to say that the last point is insignificant; people absolutely do reuse their passwords, if given the chance, and not unnecessarily exposing those is a worthy goal.

So maybe we could write something along the lines:

• The recommended authentication method for clients and servers is apiKey, but clients should be prepared for it not being supported on all servers
• The clients should be prepared for the t+s not being supported on the server
• The server may also accept an API key passed as a plain password. Servers are discouraged from accepting user-selectable passwords if they don't support the t+s authentication.

[Tolriq]

Brute force vs rainbow still matter a lot. And API calls are limited to what the API expose. Password give full access to the server interface with a lot more access and permissions. They can reply apiKeys too.

[lachlan-00]

Moving the token and/or the salt to a header would solve some of those issues? At least remove it from the url and the logs which would be helpful.

As a server, I don't think removing support entirely is a good idea but updated docs and allowing servers to optionally error 42 on deprecated auth (As long as the clients are aware it can happen) means it will go away in time.

[epoupon]

I finally added t+s support in https://github.com/epoupon/lms/releases/tag/v3.79.0
There are just too many clients that only support that method...

Since in LMS the subsonic password is the API key, which is stored in plaintext in the db, implementing this method isn't any less secure than the plaintext password.
Worth noting: since LMS switched to a dedicated API key for Subsonic auth, API methods related to account management were removed (everything related to password management).
I would say all the legacy Subsonic auth methods should be deprecated, along with all the user management methods other than listing.

[dmdeller]

Similar to LMS, Radiccio Server only accepts API Key from OpenSubsonic clients. It accepts the API Key via 3 of the 4 auth methods (apiKey, t+s, and plaintext p).

It wouldn’t be difficult to add support for hex, I honestly just forgot about it until now, and no one has reported it to me…

Unlike most other servers, it has no concept of passwords anywhere, because it is mainly a single-user native Mac app and doesn’t have any kind of web UI to log into.

[dmdeller]

I’m not sure if we can reach consensus on this, but there seems like enough concerns that I think we should try. And there are enough servers that are already diverging from the spec that I think it’s becoming more of a problem. The original reason I started this thread was because a lot of us client developers were surprised to learn that what many of the servers are doing was different than what the spec says.

So, I have written a PR for some changes to this, and then we can discuss further and see if we can work towards something we can hopefully all find acceptable: #278

If anyone else would like to try a different approach, please feel free.