Jitsi-meet: Choosing a meeting name is insecure by default

[julianfoad]

Description

In real life just now, I chose a simple meeting name, something like "MyFamily" (but not that) and hit "Go". I saw and heard six elderly people whom I don’t know, talking to each other, looking surprised to see me and saying “Oh, who is that?!”

Their privacy was violated to me, and mine to them.

This is insecure by default, and inconsistent with claiming "security".

Reported here: https://blog.foad.me.uk/2020/03/26/jitsi-meet-excuse-me-who-are-you/

I assume what I encountered was an ad-hoc meeting set up by visitors without an account, using the "choose a meeting name, tell it to your friends" method.

---

Current behavior

On entering a simple meeting name there is a real chance of walking in on someone else's meeting, uninvited.

---

Expected Behavior

On entering a simple meeting name, there should be some protections in place to prevent walking in on someone else's meeting, uninvited.

---

Possible Solutions

There are several possible solutions and measures, including...

• explain about the random phrase and its security implications and make accepting the suggested phrase a more discoverable option;
• have the "create meeting" UI user choose whether they want a public/open meeting or a private/closed meeting;
• if a user-specified meeting name is chosen for a new meeting, then very strongly encourage setting a password (unless explicitly chose to start a public meeting);
• when "start a new meeting" UI leads to joining an existing meeting, that is a violation of expectation, so interpose a second step, e.g. "this already exists; try to join it or choose another name?"
• interpose a "new user is knocking on your door" step whereby existing participants have to explicitly accept the new user;
  etc.

---

Steps to reproduce

• one user uses the "Start a new meeting" UI using a common phrase like "MyFamily" as the name;
• another, supposedly unrelated user uses the "Start a new meeting" using the same common phrase like "MyFamily" as the name;
• see that they join, without protection;

---

Environment details

Using https://meet.jit.si/ on 2020-03-26.

[saghul]

Hi @julianfoad, thanks for the report! You're absolutely right, with the increased usage we are seeing in the platform chances of collision are a lot higher and we have received similar reports. This is not something we had foreshought, sorry for the trouble it caused you.

We are working on solving this at the moment.

The first iteration will involve warning users when a too short / simple meeting name is provided, in addtion to using the random room name generator on mobile as well.

[julianfoad]

Thank you. Please file/link the relevant (sub) issues so anyone can follow along or help out. I couldn't find any.

[saghul]

There is nothing to link to just yet.

[Jcolnz]

Hey Sagul, do you have a proposed solution we can use in the meantime to prevent this happening? (Other than choosing extremely obscure meeting names). Can we easily prepend/append strings to the meeting name?

[saghul]

@Jcolnz you can type anything you want, or let the room generator generate one for you. If you are on mobile, worry not, it's coming really soon: https://github.com/jitsi/jitsi-meet/pull/5420

[julianfoad]

Those are not solutions to this problem, they are just related to it.

[saghul]

I didn't claim otherwise. A fix is being worked on.

[julianfoad]

OK, that's great! Didn't mean to sound grumpy.

[SamuelNitsche]

I am noticing the same issues. I think it would be awesome to have the ability to force meeting passwords. I know there is no configuration available but is this possible by manually updating the source code?

[rickgoud]

Isn't an easy solution to create a uuid with url : {hostserver}/{uuid}/{meetingname}?
Seems to work if you do that manually. Should be easy and secure, while keeping the possibility to just share link, right?

[saghul]

Isn't an easy solution to create a uuid with url : {hostserver}/{uuid}/{meetingname}?
Seems to work if you do that manually. Should be easy and secure, while keeping the possibility to just share link, right?

Yes, but that would make it harder to share via voice for example.

[rickgoud]

With date then? {hostserver}/{date}/{meetingname}? e.g. 2003281651 ?

[saghul]

That won’t work either, people will just put “test” on the same day and we’d have not solved anything.

[rickgoud]

there were hours and minutes in my suggestion too :) (meant datetime). But looking forward to seeing an alternative that is easy and secure!

[andresmazzo]

What if camera and microphone are disabled by default, and room has a simple password at least?

[saghul]

What if camera and microphone are disabled by default,

That will come, but it's not part of this change.

[saghul]

To be clear, what we'll be doing here, to start with, is to warn users that their chosen meeting name is not unique enough and provide suggestions, but we won't spot them from joining a meeting called "test".

As with anything, the plan is to start making changes here and refining as we go along.

[SamuelNitsche]

I repeat myself but what you all suggest is not the solution for the problem. The real solution is (as I said before) to force users to enter a meeting password.

[saghul]

I'll repeat myself too: we are looking at this problem from multiple angles and will be implementing several fixes.

[Jcolnz]

Forcing users to have a password on a meeting is also not the solution, although it is a solution. I don't understand the constraint of having the URL be sharable by voice? Most meetings will be shared via the calendar or invite link? Even if I want to share it verbally it's not much harder to say meet.jit.si/75548/meetingName than without the number. This reduces the chance of meeting collision without affecting what I can only assume is 95% of use cases.

[SamuelNitsche]

Forcing users to have a password on a meeting is also not the solution, although it is a solution. I don't understand the constraint of having the URL be sharable by voice? Most meetings will be shared via the calendar or invite link? Even if I want to share it verbally it's not much harder to say meet.jit.si/75548/meetingName than without the number. This reduces the chance of meeting collision without affecting what I can only assume is 95% of use cases.

In my case sharability by voice is really important to maintain a simple solution. Forcing a password is THE solution for exactly this issue. With forced password, meetings are secure by definition. Maybe I overlook something. Please tell me if so.

[julianfoad]

"Forcing a password is THE solution" -- What exactly is your proposal?

[SamuelNitsche]

"Forcing a password is THE solution" -- What exactly is your proposal?

My proposal in an option in the instance config to enable "force meeting passwords". The UI should include a new input for the room password. If "force meeting passwords" is enabled, the user can only continue if a password was entered. If the option is disabled, the user can continue to the meeting without a password. I hope this makes it clearer.

[tillsanders]

I believe, configuration is key, here. Clearly, there are different needs to address.

Smaller servers probably shouldn't be forced to use passwords, because that might lead to them always using the same one.

Corporates clearly need stronger protection. Possibly a strong generated password or a unique room name. Maybe even a way to grant users access individually.

No solution will match all use cases, so the level of security measures should be configurable.

[beejaz]

If you and your family goes to a public mall and enters a room and then close the door without locking the door, people will eventually open the door and join in if the mall gets crowded. If you and your family had instead locked the door (set a password in jitsi world) the random people wouldnt have been able to enter the room. I dont see how this is insecure by default, its common sense.

[tillsanders]

@beejaz If you put it like this, yes, it is common sense. But comparing the real world to the internet is oversimplifying things. For example: Obviously, we can agree that most members of society are aware of the concept of locking the door of, let's say, the lavatory. Yes, that is common sense. But this doesn't at all mean, that everyone knows how to apply this concept to a chat software they might have never even used before. Assuming, that users always and immediately know how things work – in fact, assuming, that they are always able to make the best choice for themselves – leads to bad security and user experience.

TL;DR: If you want users to make the right decisions, you have to guide them. And when it comes to their own safety, you occasionally even have to apply a little bit of force.

[tillsanders]

One more thought on this: security measures are only effective if everyone knows how to use them.

There are many possibilites, how this could be improved. For example:

1. Implement a server-wide setting that forces users to set passwords for every room they create.
2. Implement a server-wide setting that generates long and random strings for every room. Only the people with the right URL can even find the room.
3. Implement a server-wide setting that forces someone inside the room to grant access to other people joining (as if they were knocking and you are watching them through the spyhole).

These are just some ideas. Some could even be combined. For example: Users would create the room in the same way, they do now. Every room gets a long, random URL that grants immediate access to the room. People that don't have this URL (maybe because the URL is too long to spell on the phone) can still join the room by its human-friendly name, but will then need to be granted access from someone inside.

So many possibilities! It would be amazing to have some of them 👍

[SamuelNitsche]

One more thought on this: security measures are only effective if everyone knows how to use them.

There are many possibilites, how this could be improved. For example:

1. Implement a server-wide setting that forces users to set passwords for every room they create.
2. Implement a server-wide setting that generates long and random strings for every room. Only the people with the right URL can even find the room.
3. Implement a server-wide setting that forces someone _inside_ the room to grant access to other people joining (as if they were knocking and you are watching them through the spyhole).

These are just some ideas. Some could even be combined. For example: Users would create the room in the same way, they do now. Every room gets a long, random URL that grants immediate access to the room. People that don't have this URL (maybe because the URL is too long to spell on the phone) can still join the room by its human-friendly name, but will then need to be granted access from someone inside.

So many possibilities! It would be amazing to have some of them 👍

Can't agree more. I really hope that some of this ideas can be implemented.

[beejaz]

I personally likes the idea stated in 3) the most, if a "short name" has been "taken" for the moment with active users and someone tries to access it, a notification would display for either all of the people (because moderator might be away atm) that shows "Someone called X has asked to join the room" or simular and would then be granted if any member press OK.

I find option 2 less user friendly if we are talking about users to be able to spread the url by mouth

Option 1 is OK but we like it to be able to not use a forced password, we as in my company.

[tillsanders]

What is most important with any of the solutions here, is that they are configurable. It's okay, sometimes even necessary to force security measures on end users. It is not advisable to force them on technicians who actually understand the implications and can decide, what their use case actually requires.

[fpesari]

I repeat myself but what you all suggest is not the solution for the problem. The real solution is (as I said before) to force users to enter a meeting password.

I agree with this, to avoid people who do (possibly script-based) "room scanning" (either trolls or advertisers), I think each host should be asked

Do you want to secure your room with a password? 
[] Yes 
[] No

upon creating a room.

[SamuelNitsche]

I repeat myself but what you all suggest is not the solution for the problem. The real solution is (as I said before) to force users to enter a meeting password.

I agree with this, to avoid people who do (possibly script-based) "room scanning" (either trolls or advertisers), I think each host should be asked

Do you want to secure your room with a password? 
[] Yes 
[] No

upon creating a room.

I don't think so. As the administrator of my company, I may have to ensure that users are securing the room with a password. Some users never set a password if they don't have to. That's the sad truth.

[fpesari]

I don't so. As the administrator of my company, I may have to ensure that users are securing the room with a password. Some users never set a password if they don't have to. That's the sad truth.

I agree with you 100% (see my previous issue #5579), however some users above expressed the opinion that always-on passwords could make Jitsi Meet look harder to use.

I invite everyone to look at this article to have an idea about how dangerous things could get (Zoom is going through these issues)

[tillsanders]

Again, let server administrators decide, if they want to force passwords on their users or not. That way, everyone is happy 👍

[fpesari]

Again, let server administrators decide, if they want to force passwords on their users or not. That way, everyone is happy +1

Administrators can always choose, because they have the knowledge to do so. Changing the default would not affect them, they can just change the defaults to whatever they like (and since Jitsi Meet is free software, modify the whole program if they really want) :smile:

I think most people are talking about meet.jit.si specifically, and in general about all those users who aren't tech savy enough to know how to prevent call intrusions.

After all we are hearing about Zoombombing, I think it would be unwise to ignore that the same could happen to Jitsi Meet. And if that happens, its reputation will take a hard hit, and perhaps some people who are using it will abandon it because they feel unsafe.

[SamuelNitsche]

Administrators can always choose, because they have the knowledge to do so. Changing the default would not affect them, they can just change the defaults to whatever they like (and since Jitsi Meet is free software, modify the whole program if they really want) 😄

I think most people are talking about meet.jit.si specifically, and in general about all those users who aren't tech savy enough to know how to prevent call intrusions.

After all we are hearing about Zoombombing, I think it would be unwise to ignore that the same could happen to Jitsi Meet. And if that happens, its reputation will take a hard hit, and perhaps some people who are using it will abandon it because they feel unsafe.

I don't think that's true. I'm talking about self hosted instances. I myself am very tech savvy, but to expect to know every single component of Jitsi Meet completely is a bit exaggerated. Even for a system administrator. At least I don't know any method to require passwords.

[fpesari]

I don't think that's true. I'm talking about self hosted instances. I myself am very tech savvy, but to expect to know every single component of Jitsi Meet completely is a bit exaggerated. Even for a system administrator. At least I don't know any method to require passwords.

I apologize, then :bowing_man:

Perhaps a simple boolean value in config.js for always-on passwords and an explaination in the Wiki would make things easier.

[tillsanders]

Administrators can always choose, because they have the knowledge to do so. Changing the default would not affect them, they can just change the defaults to whatever they like (and since Jitsi Meet is free software, modify the whole program if they really want) 😄

I don't think, we're talking about changing the default settings. We're requesting additional or refined features. To be honest, I don't care to much about the defaults. I care about the options 😄

I think most people are talking about meet.jit.si specifically, and in general about all those users who aren't tech savy enough to know how to prevent call intrusions.

I'm talking about self-hosted instances as well. But obviously, implementing some of the ideas mentioned above would ultimately benefit meet.jit.si as well, which is a good thing 👍

[rickgoud]

Any update on addressing this issue @saghul ? Very much looking forward to the proposed solution!

[Boesboes]

Why not simply make all new meetings generate a unique id automaticly? So if i create a meeting called test instead of creating the link: https://jitsit.myserver.com/test/ make it: https://jitsit.myserver.com/random string of chars/test/

[alfonsolsl]

This is important but it is understandable that a bad implementation ruins the reasons why I am using your alternative.

I am a teacher and I am afraid that some of my colleagues who use this tool will not protect their classes and something bad could happen with a lot of children in the room. We are not a big school and we do not have the technological resources to use a private server so we are "exposed to the world". Your alternative is just easier than Zoom and our population is mostly non tech families so it's working.

What I have done and has worked is that I always put the same password, a phrase that my students already know, like PSK in a VPN, that can be from a nickname to a specific word, that adds the security layer that I need, but since it does not come by default in the system I fear that my colleagues forget to do it.

• So my idea is that the application in the first start request create a PSK to ensure by default each meeting generated by that specific user/device.

So bombing is possible but only if the info leaks.

• wait room by default was a good change by Zoom.
• Start a meeting with camera and mic disable by default has my vote too.

Good luck and good job!

[kousu]

Choosing a meeting name can be insecure, but the default room name suggestions are picked xkcd-password stlyle, so those are already strong and unguessable. Plus there are multiple Jitsi servers in the world to temper the issue a lot; it's not at all like Zoom where there's a single namespace and it's made up of numbers that can be scanned.

I also think room passwords are redundant. If you want a private room you can just put the password you would have set on the end of the URL, like https://meet.jit.si/ChemistryClassRU-Hfdsdj983FD8fa. A password on a room is essentially just a longer part of the procedure that users need to be instructed in, and anytime you need people to do something manually you encourage them to pick the shortest (weakest) version of it. A forced password is just going to end up with people picking "password" for their passwords.

I agree that should be helped along by UI. What if you take @fpesari's UI suggestion but instead of a room password, if someone has typed in their own room name, prompt them:

Your room name is short enough to be guessed by strangers.
Do you want to secure your room?
[] Yes 
[] No

and if yes, then generate https://meet.jit.si/$CHOSEN_NAME-$(xkpasswd).

Keeping xkpasswd in the mix means the room can still be joined vocally, while still being secure.

Long unguessable tokens in URLs is how Google Docs share links work, it's how Nextcloud Share links work, it's how PrivateBin and Privnote links work. It's a good system and it stays out of the way!

And if someone wants to explicitly pick a short vanity URL I think that's on them. Maybe warn them, but let them use it the way they want.

Thanks to the Jitsi team for the software and to everyone here trying to improve it!

[chipechop]

I quote every single word!

I also think room passwords are redundant. If you want a private room you can just put the password you would have set on the end of the URL,

Yeah, this is very smart!

[jimmont]

Use a domain based approach where the organizer's own email address is the source or the service host is used as the default? Then follow that down to host various specific meetings?

tied to organization:
https://meet.domain/domain:generated-hash-makes-it-sortof-anonymous
https://meet.domain/domain@user:makes-it-whatever-is-here

tied to individual
https://meet.domain/user@domain:user-generated-or-optional-hash

examples:
https://meet.jit.si/apple.com@steve:shareholder-meeting
https://meet.jit.si/[email protected]:internal-call
https://meet.jit.si/unknown@anonymous-hash-thingy <- explicit anonymity, human readable
https://meet.jit.si/apple.com@anonymous-hash-thingy <- separated large group from general
https://meet.jit.si/us.apple.com@help:iphone-se-preorder
https://meet.jit.si/[email protected]:anonymous-hash-thingy-private-meeting

[julianfoad]

@jimmont Can you please clarify how your suggestion might solve the described issue? It doesn't look to me that it does. You assume there is an "organizer" whose email address is known; I don't think that is the case for the casual kind of use that I encountered. I think what I encountered was an ad-hoc meeting set up by visitors without an account, using the "choose a meeting name, tell it to your friends" method. (I see I didn't describe that originally.)

[Manum999]

Hi everyone, I’ m new here. I’ m not a developer, just a user of technologies I want to be secure. I don’t have any personal server and I even don’t know if I can buy one for my home. I read all the discussion but today I still don’t know if Jitsi meet is totally secure or not. I use it for private and job uses and please can you tell me : are the iOS app and pc browser website system totally secure and encrypted ? Are they end-to-end encrypted ? Is there a difference between the website app and the desktop app for pc ? Sorry if I ask boring questions. Thank you.

[julianfoad]

@Manum999 This is a discussion about a specific issue. Your comment is off-topic here. For questions like that, please use a general questions-and-answers forum.

[Manum999]

Ok thanks. Thought it was the topic as people are talking about end-to-encryption and passwords to secure rooms and discussions.

[Manum999]

If somebody could still give me a quick answer that would be nice, thank you... ^^

[julianfoad]

@Manum999 please stop asking in here. You are "spamming" this issue.

[kousu]

@Manum999 I'm willing to help answer your questions. Since you haven't posted an email, you can find mine on https://github.com/kousu/.
(sorry for spamming the issue some more, I'll delete this once they get in contact with me)

[julianfoad]

@markseu Your comment is not on the topic of this specific issue #5407. Please post your additional issues and general feedback in appropriate places.

[kousu]

I quote every single word!

I also think room passwords are redundant. If you want a private room you can just put the password you would have set on the end of the URL,

Yeah, this is very smart!

Also, it's basically what Zoom has decided to do. Their web-invites look like: https://<region-specific-server>.zoom.us/j/1111111111111?pwd=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx now.

[luixxiul]

cf: https://github.com/jitsi/jitsi-meet/pull/6754

You will be notified when you are trying an insecure room name.

[MagicFab]

Thanks for this change. I've had some feedback from users alreay. I' d like to submit a few suggestions to improve the implementation.

This is the resulting warning, at room creation :

• Perhaps use this or similar text : "This room name is too common. Please consider using another name or setting a password as soon as you start using it.". It needs to be immediately helpful, remain short, non-technical and provide a quick solution directly related to the issue. Using "insecure" in English and other languages in this context will be confused with a technical security issue, potentially harming trust on the public Jitsi Meet instance and on the underlying server software, including its technical security features and advantages (both perceived and real).
• The persistent warning icon after choosing a bad room name is scary and doesn't exactly relate directly to a bad choice in the room name. A red banner across the screen may be more effective.
• Room names can't be localized yet (see #6694) so I am not sure if the "unsecure name" detection will work in other languages.

Can we please consider changing the wording, and make it configurable ?

[saghul]

Can we please consider changing the wording, and make it configurable ?

Feel free to suggest different wording in a PR, as for configuration, I don't think we want to make it configurable (I assume you mean the text) because of localization.

Note that this is our first iteration, so expect refinements as we move forward.

[MagicFab]

Feel free to suggest different wording in a PR

I'm requesting feedback before doing this, thank you.

I don't think we want to make it configurable (I assume you mean the text) because of localization.

No, I meant having an option to completely avoid this test & warning, see here.

[saghul]

No, I meant having an option to completely avoid this test & warning, see here.

Right. Yes, a config setting to disable it (in interface_config I'd say) would be fine!

[bluikko]

@saghul Indeed configuration option would be important. Current behavior will confuse corporate users where the server may not be open to public at all, there have already been panicked questions about it.

The wording could also be improved in my opinion. The word "insecure" is true in a way, but in my opinion "easy to guess" or "common" would explain what the message is really about without confusing/frightening users.

IMHO this whole thing is totally overblown. Someone picked a common room name, didn't set a password, oh gee someone guessed the room name!, and made a ruckus. I am fine with designing software for the lowest common denominator as long as there are knobs to make it reasonable for the rest of us.

Edit: just found #6801 so it seems my points are already being addressed.

[saghul]

Yes, we are making improvements to this, it's a bit rough at the moment, apologies for that. It now (on master) defaults to disabled, with an option to turn it on.

[pandel]

Yes, we are making improvements to this, it's a bit rough at the moment, apologies for that. It now (on master) defaults to disabled, with an option to turn it on.

@saghul Yes, it is really getting better. After my critics the other day I have to say that it improves step by step. Many thanks for that.

A question regarding the config option: will it be possible to disable this feature via iOS SDK JitsiConferenceOptionsBuilder, too, at some point in time or only on the server side?

[saghul]

We can add a feature flag for the native SDKs yes.

[pandel]

A very good solution! Thanks for your fast answer :-)!

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

[jvschiavo]

I'd like to add that I really liked @Jcolnz suggestion. Having it automatically generate 4 random numbers before the meeting name (like meet.jit.si/8634/meetingName or meet.jit.si/8634-meetingName) would help to improve a lot the security of short-named rooms and without making it difficult to share by voice! :)

[bluikko]

I'd like to add that I really liked @Jcolnz suggestion. Having it automatically generate 4 random numbers before the meeting name (like meet.jit.si/8634/meetingName or meet.jit.si/8634-meetingName) would help to improve a lot the security of short-named rooms and without making it difficult to share by voice! :)

I will not comment on the suggestion of four numbers itself but want to remind that Jitsi is not always open for the public and any such messing with meeting names must be configurable.