Closed danielreuther closed 8 years ago
We could add that as an option, sure. I'll have to run some tests to be sure it works without problems first.
Just committed the changes that allow for this method of authentication. Please test and let me know if you find anything wrong with it, it seemed to work fine here.
Tested and works! Thanks a bunch for the swift fix -- it's appreciated :)
Just one detail: This issue is not limited to forks of Subsonic, it's something that's inherent to the design of that new auth mechanism (and thus also affects 6.0+). It requires the server to store passwords in clear text in order to hash them using the client-generated salt.
[edited for clarity]
Thanks for reporting back. I know this is a feature included in Subsonic from the older versions, just wanted to highlight that it was put in place because of this request. :)
This is a known limitation of the new "token-based authentication" of Subsonic (I already described it over here): Since Subsonic doesn't have access to the clear text password, it cannot md5 it with the client-submitted random(!) salt. This is a severe design limitation. Alas, there's not much we can do about it apart from asking client developers to not use that form of authentication.
Any chance that an advanced configuration option could be added that allows falling back to the older scheme in which the hex-encoded password with "enc:" prefix was submitted? (documentation can be found here)
If SSL is used this shouldn't be significantly less secure (on the contrary, it allows the server side to store hashed passwords).
Thanks!