password not enforced if someone is already waiting for host

[S74HK9hV]

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

---

[munak1985]

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.

[alpianon]

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...

[c-goes]

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

[saghul]

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

[ovari]

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

[damencho]

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.

[ovari]

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

[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.

[c-goes]

Lobby doesn't seem to fix this.

[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.

[c-goes]

Is this now possible with lobby?

[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.

[dsvk]

Still a valid issue. Neither the lobby nor a password will mitigate bombing by someone already waiting before moderator joins. The moderator needs to be able to enable the lobby and/or set a password before they actually open the meeting.

As mentioned in https://github.com/jitsi/jitsi-meet/issues/5720#issuecomment-627817220, lobby itself could also have password protection (separate from the currently implemented password which is effectively a lobby bypass). These passwords could conveniently coexist - first one being shared to regular attendees (to only let them into the lobby for subsequent moderator approval) and the second "privileged" password only being shared among meeting admins/moderators, if needed.

Edit: also related https://github.com/jitsi/jitsi-meet/issues/7385 (FR for 'lobby on by default').

[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.

[dsvk]

Still valid.

[james-green-affinity]

:(

[github-actions[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.