Jitsi Bombing

Hi there,

I’m a teacher who has been using jitsi to keep my courses going during the situation we find ourselves in right now. Zoom bombing and Teams bombing have been happening to teachers at my college, but Jitsi has been fine - until this past week. Now, more and more, Jitsi is falling victim to this same treatment. I want to keep using Jitsi - I don’t want my students to have to register for anything or download anything (it’s difficult for them), but I also don’t want them to have to deal with Jitsi bombing. Any suggestions on how to prevent this from happening?


Once you enter the meeting you can define a password
bottom-right corner -> information icon -> define password
and then send it to your students.
Prevents anyone entering the room without having said password.



If, of course, your students share the password, then anyone who has the password can join the room, so impress on them the importance of not sharing the password.


I’ve been using the password, but here’s my question: Once everyone is in the room, can I change the password to something else so no one else can enter?

Good question.

I’ve just tested it on meet.jit.si and, yes, apparently you can change the password after the room has been created and people have entered. New entrants need to enter the new password, and existing participants do not have to enter the new password and are not kicked out. (If they left the room, they’d need the new password to get back into it through.)


Thanks so much for testing this out - this might be my solution!

1 Like

Another solution may be to use four random words as the room name and have no password. There is no public list of Jitsi rooms, so Zoombombers are just trying random room names. Even if they can try 1000 every second, picking four random words from a dictionary would be too computationally difficult for them to crack. (On average, it will take them over 500 years to find your room, by which time your class may be over).



I had the same issue. If you choose a weird name, and even a stronger password, students can still share these 2 things by various reasons, so the whole thing goes back in the corner.

This requires extending the original API and deal with login to rooms in a different way. I am still trying to see where to start. If anyone can point us to the key points, would be really helpful.

On your own Jitsi installation you can use JWT authentication to securely lock your room from intruders. The students and teachers enter the room through some portal which uses their school credentials to authenticate.

It’s like integrating to any LMS with LTI.


Yes, it’s best to have your IT department lock things down. On the other hand, for the time being, simply asking the students to be responsible about not sharing the room name should be sufficient.

Zoombombers are not bothering getting credentials from loose-lipped kids. They use a program that quickly finds hundreds of open Zoom conferences.

1 Like

After spending all day trying to fight off users naming meeting rooms “test” and “Meeting” i threw this hack job together to try and restrict it:

Add the below to your nginix config AFTER the static content and BEFORE the BOSH config:

# Landing for blocking bad meeting locations
location ~ ^/(for-your-safety)/(.*)$
    add_header 'Access-Control-Allow-Origin' '*';
    alias /usr/share/jitsi-meet/$1/$2;
    location ~ \.php$ {
      fastcgi_split_path_info ^(.+\.php)(/.+)$;
      fastcgi_pass   unix:/var/run/php/php7.3-fpm.sock;
      fastcgi_index  index.php;
      fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
      include        fastcgi_params;

# Block known bad meeting names to prevent Zoomboming
location ~* ^/(test|testmeeting|staffmeeting|meeting|test[0-9]+)$
    rewrite ^/(.*)$ https://<YOUR FULL URL>/for-your-safety/index.php permanent;

Add more names as you please separated by |
If you are not running PHP (i am so that i can do some fun stuff and generate random strings) remove the PHP stanza and adjust as needed.

Make a folder in the webroot (mkdir /usr/share/jitsi-meet/for-your-safety) and add your file as needed

Someone with more nginx chops could probably change it so you don’t need the Full URL, but at 10:30 on launch day i cracked it and needed a quick fix.

I made a page that says

For an extra layer of security, name your meeting something completely random such as bfedwbgtrweberf

Click here to start a meeting using that random name -OR- Click here to go back to the homepage and pick your own name

Users! Bloody users!!! No matter how many times you say “Set a password” they still don’t!

We’re also in the edu space, and use JWTs since only authenticated users can join conferences. The JWT comes from Auth0 in our case. So far so good.

One extra problem is a user turning rogue - how do you prevent them from re-joining the room after kicking them?

The solution we’ve thought of is to monitor the participantKickedOut event, and if the user got kicked twice within X hours, invalidate their JWT and block them via your user management API.