Let me explain a little about the motivation behind all this. I recently started working on my own implementation of an OpenSubsonic API server (Tocata), and I realized that the method typically used by default in API calls, the so-called token, is not only completely insecure when transmitted over HTTP but also highly counterproductive.
The token is, basically, an MD5 hash of the password and a salt (which is also included in the request itself). If that request is intercepted, the attacker is already in, and from there, extracting the password is relatively simple using a brute-force attack. In other words, protecting the password with an MD5 hash is useless in this case and forces you, at the server level, to store passwords either in plain text or using a reversible encryption, which is inherently insecure by design.
Given this, there are only two options left (to store the password using strong, non-reversible encryption). One is to switch to legacy mode, and the other is to log in using an API key.
Legacy mode simply involves sending the password in the p field, preceded by an enc: and hex-encoded. IMHO, this mode offers exactly the same security as sending the t and s, because if your packet gets intercepted, you're screwed. It is true that the token mode takes the brute-force attack to the next level, but the attacker does not actually need to decode the password, since the same salt can be used indefinitely.
Obviously, the most modern approach is to support API Key Authentication, but that requires a slight shift in mindset, since in that case the username does not travel (and not all servers support it).
Ideally, you should support both methods (this allows you to reach all server implementations), but if you're not convinced by that, it would at least be very worthwhile to support the modern method.
Let me explain a little about the motivation behind all this. I recently started working on my own implementation of an OpenSubsonic API server (Tocata), and I realized that the method typically used by default in API calls, the so-called token, is not only completely insecure when transmitted over HTTP but also highly counterproductive.
The token is, basically, an MD5 hash of the password and a salt (which is also included in the request itself). If that request is intercepted, the attacker is already in, and from there, extracting the password is relatively simple using a brute-force attack. In other words, protecting the password with an MD5 hash is useless in this case and forces you, at the server level, to store passwords either in plain text or using a reversible encryption, which is inherently insecure by design.
Given this, there are only two options left (to store the password using strong, non-reversible encryption). One is to switch to legacy mode, and the other is to log in using an API key.
Legacy mode simply involves sending the password in the
pfield, preceded by anenc:and hex-encoded. IMHO, this mode offers exactly the same security as sending thetands, because if your packet gets intercepted, you're screwed. It is true that the token mode takes the brute-force attack to the next level, but the attacker does not actually need to decode the password, since the same salt can be used indefinitely.Obviously, the most modern approach is to support API Key Authentication, but that requires a slight shift in mindset, since in that case the username does not travel (and not all servers support it).
Ideally, you should support both methods (this allows you to reach all server implementations), but if you're not convinced by that, it would at least be very worthwhile to support the modern method.