Jitsi-meet: password not enforced if someone is already waiting for host

Created on 6 Apr 2020  ·  9Comments  ·  Source: jitsi/jitsi-meet

This Issue tracker is only for reporting bugs and tracking code related issues.

TL;DR - meeting password protection can be bypassed by simply showing up in a meeting room before the host arrives.

Description

  1. authentication for room creation is already setup in prosody
  2. users (non-host, non-admin) are waiting in room (https://jitsi.example.com/roomName)
  3. users get message that meeting is waiting for host
  4. host logs in to meeting using credentials set up in prosody
  5. all waiting users from step (2) are immediately placed into meeting with access to video/audio from other users
  6. host is given the option of setting a password on meeting
  7. host inputs a password to protect meeting
  8. all NEW users after step (7) are asked for password

The problem is that one of the users from step (2) might not be welcome in the meeting. Could be someone who got the link by accident or enumerated the meeting link. You now have unauthorized users in the meeting with access to everyone's audio/video even though the meeting should be password protected. Therefore, password protection is defeated by simply showing up early to the meeting.

enumeration is unlikely if you generate random room names (not really a built in option at this moment) but a lot of people are using room names like "familyChat" or whatever, so enumeration is pretty trivial. but even if we have strong and random meeting room names, (ie. jitsi.example.com/a6f9c2b6e1dd) we still want to protect against the link being shared with the wrong people


Current behavior

Once the host authenticates, all users waiting for host are automatically placed in meeting without inputting password


Expected Behavior

Password should be enforced on ALL users in the meeting, even those who were already waiting for start


Possible Solution

BEFORE meeting becomes active, host should have the option to enter password, or make the meeting unprotected.

THEN the meeting should become active, and those waiting for meeting start must enter the password, or meeting should start if no password required


Steps to reproduce

  • setup authentication on prosody
  • have one or more users waiting for a meeting to start BEFORE the host arrives
  • authenticate as host using auth set up in prosody
  • meeting then starts immediately
  • admin can still set up password, but anyone who was already waiting for the meeting is already in the meeting with access to everyone's video/audio streams

Environment details

debian 10 buster stable, 4.19 kernel
nginx 1.14.2
jitsi-meet 2.0.4384
prosody 0.11.2

tested on clients: jitsi android, chrome windows, chromium debian, firefox win/debian


mobile privacy web

Most helpful comment

We are in the process of implementing a “lobby” feature, I think it would cover this use case as well.

All 9 comments

Regarding a possible solution, on the login dialog for a host/moderator to start a meeting, there could be a third widget where the room password could be entered.

Regarding a possible solution, on the login dialog for a host/moderator to start a meeting, there could be a third widget where the room password could be entered.

but I guess that if moderator is already logged in, this would not work...

enumeration is unlikely if you generate random room names (not really a built in option at this moment)

When you leave the room name empty, a random name (passphrase) is used

We are in the process of implementing a “lobby” feature, I think it would cover this use case as well.

If we understood Zoltán (Jitsi developer) correctly during the Community Call of 27 April 2020, a password can be set or the moderator accepts participants. Did he refer to this feature as "knock-knock"? Is this the same as the "lobby" feature?

Once the "lobby" feature is implemented, will it be possible for the moderator to require a password from the participants before they will allowed into the "lobby" (i.e. "waiting room") for the moderator to accept them?

Thank you

Yes this is the lobby we are working on. Moderator/s will be able to accept/deny participants or participants can use a shared password(the room password) if set, to skip the knocking/to skip the waiting for approval and directly join.

Thank you for your reply.

A competitor to Jitsi has both room password and waiting for moderator approval. Can this be implemented in Jitsi too?

  1. room password can filter out people from accessing the lobby (aka waiting room) and save moderator time as they would never see these participants.
  2. moderator approval can filter out people from directly accessing the room. It can help if a participant posts the room password on a social network. This can help reduce the chance of Jitsi-bombing.

Does the above help explain why having _both features_ available at the _same time_ is beneficial?

Thank you

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.

Lobby doesn't seem to fix this.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

TopheC picture TopheC  ·  3Comments

ranjithrajv picture ranjithrajv  ·  3Comments

samk17cmutpm picture samk17cmutpm  ·  4Comments

TechnologyClassroom picture TechnologyClassroom  ·  3Comments

mdosch picture mdosch  ·  3Comments