mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
[Issue]: User/Pass sent in cleartext #5186
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @CaryRoys on GitHub (Oct 26, 2023).
User/Pass sent in cleartext during login
Security best practices dictate that a cleartext password should never be sent over the wire, but instead a password hash which is validated against a hash of the password stored in the database.
Steps to reproduce:
You will see a JSON blob like so:
{Username: "username", Pw: "password"}
What is strange is, the password appears to be stored hashed in the database. The remediation for this is to generate the hash client-side and send that across the wire. Some remediation can be accomplished by using HTTPS, but this is still vulnerable to a MITM attack.
I do not know if the same issue is present in any of the client applications (yet). Will investigate and update.
Jellyfin Version
10.8.9
if other:
No response
Environment
Jellyfin logs
No response
FFmpeg logs
No response
Please attach any browser or client logs here
No response
Please attach any screenshots here
No response
Code of Conduct
@cvium commented on GitHub (Oct 26, 2023):
So you're saying the OAuth2 spec is insecure? Hopefully, whoever exposes their server to the public are smart enough to use TLS.
Nonsensical. Now the hashed password is the password, which you're sending in plain text over the wire.
@CaryRoys commented on GitHub (Oct 26, 2023):
To your point @cvium, the OAuth2 spec has this to say:
https://www.rfc-editor.org/rfc/rfc6749#section-1.3.3
The authorization server MUST require the use of TLS as described in when sending requests using password authentication.
https://www.rfc-editor.org/rfc/rfc6749#section-2.3.1
Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with
the authorization server.
If we're going by the letter of the RFC, then the answer instead of sending the hash would be to refuse to function in non-TLS mode. I think that's no good for most users, who are likely using it locally.
@CaryRoys commented on GitHub (Oct 26, 2023):
Nonsensical. Now the hashed password is the password, which you're sending in plain text over the wire.
At least that hash can't easily be used elsewhere. Password security is not just about securing the one system, it's about not leaking credentials which might be re-used elsewhere.
@cvium commented on GitHub (Oct 26, 2023):
If someone wants to be stupid, we can't stop them. Our recommendation is to use a reverse proxy, which handles the TLS termination, so Jellyfin cannot determine whether the connection is secure. It is up to the server admin to make it so.
We will not add password hashing on the client side. If someone reuses their password, they are likely to have it leaked elsewhere.
@oddstr13 commented on GitHub (Oct 26, 2023):
Pre-hashed passwords where a part of Emby back when we forked (no idea if it still is), as a security by obscurity measure.
It was removed in Jellyfin 10.3 back in 2019, you can see some of the discussion following the removal in #1222.
It doesn't actually provide any additional security, as if you can read passwords, you can also most likely manipulate the sent/received data.
Re-use of passwords is a big no-no in any case, as there are still very many services out there not properly hashing and salting their password databases. Many are actually encrypting the database, as opposed to hashing, and others are still using md5/sha1, which are trivially reversed with rainbow tables or easily brute-forced using the GPU of any somewhat modern gaming PC.
If you are exposing Jellyfin, or any other service, to the internet, you must use https to avoid the many different forms of MITM attacks that exists.