Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security Enhancement in authorization #1964

Closed
Czile-create opened this issue Oct 30, 2022 · 4 comments
Closed

Security Enhancement in authorization #1964

Czile-create opened this issue Oct 30, 2022 · 4 comments

Comments

@Czile-create
Copy link

Question & Present Situation

I noticed that the password is stored in the folder with a simple encrypting method, where the encryption key is also stored in the same place, which is extremely dangerous if the storage can be accessed. I wonder if there is an improvement to this situation by storing the hash code of the origin password.

Solution

Noted that the solution should make an allowance of security both in data transmission and data storing, I supposed a new model in authorization, that is

  1. Once the password is set, the password should be stored in the formation of hashing code (e.g. sha256) (may be with a random salt).
  2. A shared public key should be generated and can be accessed.
  3. When authorizing, the client uses the public key to encrypt the password and send it to the server, and the server decrypts it with a private key and converts it into the hashing code to make comparisons with the one stored in the database, which ensure the security in transmission and storing.

Many people use the same password as they use in other important social media, which causes a potential danger to their information security if the password can be accessed in the server. However, even if the attackers attain the hashing code, they cannot compute the password in reverse (in the Mathematics meaning).

I don't know if it's easy for you to make this change, or if there are any other defects in my solution... Please feel free to contact with me.

@K4r0qtuYNE5G4qgZ
Copy link

For 2.) and 3.) there is SSL
And 1.) was not done because of #202
But of course you should never use the same password for different services.

@deluan
Copy link
Member

deluan commented Nov 4, 2022

I agree that the password encryption/storage in Navidrome is not optimal, but this is a trade-off to keep compatibility with Subsonic API. Please refer to:

As long as we want to support Subsonic clients, there's not much we can do. What you can do is:

@deluan deluan closed this as completed Nov 4, 2022
@SteveDinn
Copy link

Huh... I guess you're saying that navidrome needs its own apps :)

Perhaps navidrome users could have optional subsonic credentials that are not necessarily the same as the native navidrome credentials. Maybe even have the abillity to disable the subsonic API completely for those that don't use it?

@github-actions
Copy link

github-actions bot commented Mar 7, 2023

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants