Jitsi-meet: Room password could be send as a URL parameter

[sidan5]

Is your feature request related to a problem you are facing?
I'm trying to secure rooms using a "random"/complex password. on the other hand it must be simple enough for anyone to join the meeting (without the need to type the complex password). This kind of solution is implemented on Zoom as far as I know.
This on one hand might not be too complex to implement but would increase security dramatically. Moreover, user experience would not negatively be affected as users doesn't need to know anything for it to work.
_Real life example_: I want to connect between 2 (or more) users for a video call using a mobile app but without both (or all) need to set the room password manually (should have same UX as a FaceTime call).

Describe the solution you'd like
Add a new parameter to the URL that could contain the room password. When joining a room this parameter would automatically set room password from the URL instead of user need to insert that manually.
Also, when sharing from room UI it would be nice if this parameter and password that has been set would be added to the shared URL (the link would include password).

Example:
https://meet.jit.si/ROOMNAME#config.roomPassword="ROOM_PASSWORD"

_Expected Result_: Anyone who have access to the full URL could join the room. Clicking the URL would enter the room even if it is password protected.

Describe alternatives you've considered
_JWT_: Using JWT doesn't help as we would need to manage list of users that allow to enter a specific room (this could not be done at scale as this shall be dynamic).
_Using complex room name_: This is kind of nice but does not prevent anyone from entering a room if somehow this name is being exposed.

[ostasevych]

You may try to think to encrypt the password.

[sidan5]

@ostasevych how encryption would help?
If I want the password hidden from all users but the ones need to join the room I would need to share a key with all of the relevant somehow. This doesn’t add any security as I would need to send it somehow for all of them. So encryption by itself for the password doesn’t add anything to a “strong” password.
I see the password as the credentials to join a conversation (something only those who are creditable to join would know). For me everyone who knows it or get access to it could definitely join the room.
If I misunderstood your suggestion please let me know.

[ostasevych]

@ostasevych how encryption would help?
If I want the password hidden from all users but the ones need to join the room I would need to share a key with all of the relevant somehow. This doesn’t add any security as I would need to send it somehow for all of them. So encryption by itself for the password doesn’t add anything to a “strong” password.
I see the password as the credentials to join a conversation (something only those who are creditable to join would know). For me everyone who knows it or get access to it could definitely join the room.
If I misunderstood your suggestion please let me know.

Well, I mean, the plain password may be intercepted, while encrypted or hashed not.

[sidan5]

Well, I mean, the plain password may be intercepted, while encrypted or hashed not.

@ostasevych Let's think about those options for a second:

1. If the password is encrypted then the room participants would need to have a key distributed to them to encrypt it. Then we just make the issue more complex as I'm not sure we want this kind of feature. Also all those participants would eventually have access to the plain password and they could forward that to anyone. So I'm not sure it gives any value then just to have the password as plaintext.
2. If the password is hashed then how we would get the plain password we need to access the room? If we would use a hash function to create the password it would just "help" to make it complex enough from a simple phrase, still this need to be created with some kind of random as we won't want a guessable password (even if we used hash and it looks complex after hash function). This is definitely different from hashing a password for saving in the DB (there the hash help not to disclose the original text used to create it).

To my conclusion, as I see it, in the scenario we are talking about I do not see any value whatsoever to encrypt the password being sent in the URL or hash it. Let me know if I miss anything as I might... :)

[PacoBell]

"This is definitely different from hashing a password for saving in the DB (there the hash help not to disclose the original text used to create it)."

To me, this is exactly what is desired. The meeting organizer wants to choose a password familiar to them, but doesn't necessarily want to disclose the semantic meaning to the participants. This provides easy access to the room for anyone with the URL, yet some measure of security against anyone opportunistically scanning for public rooms with no password security (i.e. Zoombombing).

[sidan5]

To me, this is exactly what is desired. The meeting organizer wants to choose a password familiar to them, but doesn't necessarily want to disclose the semantic meaning to the participants. This provides easy access to the room for anyone with the URL, yet some measure of security against anyone opportunistically scanning for public rooms with no password security (i.e. Zoombombing).

@PacoBell I get this. However, my feature request was to have the password option available to be fetched from the URL. The exact way of creating it is a different topic to my understanding.

Anyway, If we do discuss that (hashed password), Need to understand that using a same password with hash would result with same hashed-password. That means that to prevent that we would need to create also a random salt for this hash so the host would create the hashed-password using the password he likes, some random salt would be generated then the hashed password would be created and be available for sharing. This would keep the (hashed) password being shared a "random" string in any case (it does not affect this feature request in any way but on the way password is being created).

If I would suggest a way to create the shared password I would definitely add an option of a random one created in the client by host request (or the host could just set any if he would like in any way he finds appropriate as it is today).

[Syonyk]

I'm struggling to see how adding a room password to the URL is functionally different from just using a very long and random room name in the first place. If the goal is to have people able to join "with a link," and not have other people discover the room, then a long and unique name accomplishes both goals.

If Jitsi _is_ leaking room names, then that's a separate issue that should be addressed. The problem with Zoom is that they're using nothing more than a 9 or 10 digit room ID, which can be easily brute forced. Jitsi allows long names, so the search space is massive. Don't use names like "Meeting" or "Test" or such, and the chances of someone finding it drop quite low.

If you want to generate good random room names, you can always use a hash function (sha256 or so) to generate a meeting name.

On Linux, at least, one might consider extracting some entropy from /dev/random and hashing it to make a room name.

$ head -c 64 /dev/random | sha256sum
3a97553e0dc4aac41f9457f431aa7910fdf9373baa2a628a450e29077710c820  -

That's just as good as any password, and if the URL is being shared for access, there's no difference.

[sidan5]

@Syonyk that’s a good point. I’m new to Jitsi and not sure how room name is being stored, compared and used (could check if you can refer me to the relevant point). However, as I see it, room name (on contrary to password) is a parameter I guess does not need to be handle carefully (as most passwords are). I would be very surprised if room name is handled same as required from password and in that case you are right.
On other hand, if room name is “exposed” to the world and not handled carefully as password should, I don’t think it’s a security issue by itself (same as sharing your email address with everyone is not a security breach).

[MagicFab]

Keep in mind anything used in the URL will be visible and kept in users browsing histories and server logs.

[joydeb28]

Any config params required to work this
https://meet.jit.si/ROOMNAME#config.roomPassword="ROOM_PASSWORD"

I tried the first link for setting the room with a password then tried the second link to join, but it's not working, its asking me for a password again.
http://meet.jit.si/hellojoy
http://meet.jit.si/hellojoy#config.roomPassword="1234"

[nordlolek]

Is there any news if such feature will ever be implemented?

We have similar need for setting room password on creation.
Currently our rooms are only created by jwt authenticated users, also, we don't request authentication for guest.
Moderators can set room password after they join their room, but that also means that room is created and everyone "waiting for host to join" are already joined when moderator is setting room password.

Regarding this topic I have already opened ticket at: https://community.jitsi.org/t/jitsi-jwt-which-also-sets-room-password/66660

For us It would be good enough solution if room password could be set with URL parameter when moderator is entering room.
I don't mind if guest are forced to "manually" enter room password and can't pass room password with URL - if this is security concern.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.