Hacker News Reader

Comment by yunaflox | Hacker News Reader

Does this introduce basic UX changes, like saying that a media will be permanently lost instead of "will be removed from Jellyfin" which is inaccurate?

Edit: And making it more secure? Just because it is commonly for LAN doesn't mean it can be insecure

View on HN

> like saying that a media will be permanently lost instead of "will be removed from Jellyfin" which is inaccurate?

I don't know if that changed, but I gave jellyfin only read only access to my movies.

i believe the maintainers stance is that jellyfin should not be exposed and it should always be behind a vpn

Unfortunately, yeah.

Frankly at this point, everything that is not explicitly fully public should be...

not necessarily always a VPN, but you can also use a reverse proxy like caddy or nginx where encryption and security are primary concerns instead of something non-essential like in jellyfin.

I doubt that, how would that work? You would need to give all your friends a VPN login into your local network for all of their devices, including TVs.

or your friend can setup VPN on his Router box.

But then all of his traffic goes through my internet. Unless he has a special high end router that can only route specific domains.

You dont need high end box, a old mini pc running pfsense/opnsense is enough.

High end, as in feature rich.

If you think most non tech people can just casually find an old pc, install and setup pfsense, then you are out of touch with reality. And they also would have to let it run all the time and have space for it. That's just not something realistic. It's not an option for my friends. Might also break chromecast.

Most non tech people just subcribe to netflix/hbo/disney and call it a day.

Correct, most do. Still leaves a significant portion that does not want to sub to multiple streaming services. Be that as it may, I have multiple friends who I share my jellyfin with. Giving them all access to my network is just not an option. It's not.

Tailscale. Your friend just needs to be invited to your tailnet. Super easy to use with clients on all the major devices.

Even on TV? Without their other traffic is going through network? Also for non technical people?

Yes, I have Tailscale on my AppleTV. Only traffic attempting to reach your tailnet is routed to you, the rest is on his own network.

If you want to make it super easy for non technical people also use reverse proxies to your tailnet so jellyfin/plex is reachable at like “https://watch.example.com”. Pretty much the only friction for non technical people would be creating a tailscale account and being invited to tailnet I guess. But you could also just do that for them I suppose with auth keys

Their stance is actually that exposing it is fine

Reverse proxy works fine. There’s even a setting in Jellyfin to provide the proxy IP.

Including, but not limited to, sending passwords in cleartext on login.

As opposed to what? The password needs to reach the server. Encryption is the job of HTTPS.

... as opposed to using salted hashing like in every tutorial since 1990s.

I think you have some confusion between expectations upon the client and the server. This very site (and almost every other) sends your password in plaintext over form data when you sign in.

Hashing (and/or salting) a password client-side before sending it would offer next to no protection, as if the server is expecting this value and the attacker intercepts it, they could just replay the hashed value themselves. Why would they need to know the original password?

The salt for the password should also have been randomly generated when it was first created, and stored alongside the password in the database. The only way for the client to know this value would be to retrieve it based on username alone, when the request is first made. This would reduce the security of the system and allow a dedicated attacker much more leverage to try and crack that single password, if they knew only the username of the user.

The comment you're replying to is correct, encryption is the job of HTTPS.

I don't think this is what the GP meant, but he's accidentally correct in that there is indeed no good reason for a password to reach the server.

The client could do a challenge-response PAKE with the server, proving the client held the password while not transmitting it. The session cookie could be sent from the server as part of that exchange, encrypted so only the holder of the user's password could decrypt it.

That's not how the web works, but it's strictly superior to the accepted standard of the client sending the raw password to the server, and it would be secure even over an active MITM unencrypted link.

Reply on news.ycombinator.com