anidb password in plaintext, really??????

[icf20]

Before submitting your issue, please verify the following.

• You're using the latest Stable or Daily version of Shoko Server.
• You're using the latest and correct (Stable:Stable, Daily:Daily) Web UI for the version of Shoko you're using.
• You've searched this repository (top of the page) for the issue you are reporting.

Shoko Version

5.3.3.0

Shoko Version - Daily Commit

No response

Install Type

docker

Description

  "AniDb": {
    "Username": "user",
    "Password": "PWD",
    "HTTPServerUrl": "http://api.anidb.net:9001",
    "UDPServerAddress": "api.anidb.net",

this is major security f up

Steps to Reproduce

read settings-server.json

Log File

PLACE LOG HERE

Screenshots

No response

[da3dsoul]

Yes, really. We never pretended to be secure. Don't let unauthorized access to your user folder on your server.
I'm not going to act like it's a good thing that a software older than some of its users isn't secure, but we also have more important things to worry about. It's AniDB, not your bank.

[da3dsoul]

If it makes you feel any worse, the calls to AniDB's API also have the password in the URL. Sekurty

[escape0707]

@da3dsoul Randomly stumble upon this issue, and I want to add that passing password in api call is at least in memory and ephemeral, and (should be) protected by TLS. So it's not that bad actually.

Plain text password saved in the disk is more of a convenient option than a secure one of course and besides storing it in system secret store or TPM, I think maybe run the server in a dedicated user account and utilize linux user permission to limit access is also enough for an AniFB account password. Could be a future feature but yeah, not high priority.

[revam]

@da3dsoul Randomly stumble upon this issue, and I want to add that passing password in api call is at least in memory and ephemeral, and (should be) protected by TLS. So it's not that bad actually.

Who said TLS, encryption or https was in the picture?

[escape0707]

I said should be.

[da3dsoul]

It's in the URL, not the body...

[escape0707]

@da3dsoul Usually TLS should be encrypting protecting http URL parameters but I just give a check on AniDB api and it seems that they happen to not support HTTPS, as they "should be".

[da3dsoul]

The API hasn't changed in 15 years... Believe me, we would love for it to get some TLC. Instead we've made efforts to reduce our dependency on it, though we are still far from it.

[escape0707]

Yeah I know, and I'm not blaming you guys for security reasons. I just wanted to add some commonsense context, and I guessed AniDB might not have HTTPS support, but I was too lazy to confirm y/n that day. I hope this project could continue to grow and get better and better.

[da3dsoul]

This is my opinion, but the plain text password thing has never bothered me. In order to read the plain text passwords, you need to have access to the machine, and if you have that, practically all security is moot. I agree they shouldn't be printable from the API, but I don't believe they are

[bigretromike]

A simply UUID generated to secret.json and used as salt to store in config would solved this (and leaks while sharing config files) - but then again direct access to machine would resolved in password being compromised - even better thanks to AniDB a simple packet capture software would get you a password even if salted or encrypted ;-)