Greenlight: Feature request: Increase room security

[MarcelWaldvogel]

My conclusion to the discussions in #1265, #1303, and #1331, I would propose the following changes:

1. Add a third triplet to the room ID (raises the entropy of the name from 28.5 to 42.8 bits, if the user name is known)
2. Replace the first triplet of the room ID, which is currently based on the user's name, with a random triplet (entropy from 42.8 to 57 bits) (is there an important reason to have the user name as the first chunk?)
3. Move from simple to cryptographically secure random numbers, so that the entropies listed above are actually met (the real entropy as currently implemented is lower than the maximum stated above, especially if an attacker has access to many room names)
4. Allow passing the access code as part of the join URL, but do not obviously expose the access code and do not make this passing the default

• 1 and 2 could be accomplished by replacing random_room_uid in the room model with the following:
  ruby def random_room_uid [uid_chunk, uid_chunk, uid_chunk, uid_chunk].join('-').downcase end

• 3 could be achieved by replacing uid_chunk in the same file with code similar to the one below, which would require SecureRandom.choose to be public API, which for some obscure reason it is not, so the code would be longer or less secure:

  require 'securerandom'
  
  def uid_chunk
  charset = ("a".."z").to_a - %w(b i l o s) + ("2".."9").to_a - %w(5 8)
  SecureRandom.choose(charset, 3)
  end
  

  Due to the lack of SecureRandom.choose as public API, the resulting code would be rather complex. After deliberation, I therefore do suggest to leave uid_chunk as is, even though the entropy would be slightly lower.

• 4 could be achieved by code similar to #1331, allowing the access code to be passed in the URL as ?code=123456. However, unlike #1331, the code would not be shown on the main page, but only in the room creation/settings dialog, where the access code is displayed anyway (see discussion in #1331). I would suggest to change the access code field as follows:

  • Add a clipboard copy icon to the currently existing dice and trash icons embracing the access code field
  • The clipboard copy icon would have a tooltip saying "copy room URL including access code"
  • The other icons should also get tooltips for consistency
  • Place the dice and trash icons left, and the clipboard copy icon right of the field

Looking forward to your comments.

Cc: @lkiesow

[MarcelWaldvogel]

Would also reduce the impacts of #1311 and #1373.

[lkiesow]

I like that plan.

One additional idea to make getting the access code easier would be to add an additional button right next to the current button like this:

The functionality could be to either just be a simple button like depicted here, or to have a drop-down to select something like “show access code”, “copy access code”, “copy room URL with access code”

That said, these are just a few random thoughts. I haven't thought this through very well yet and I'm generally fine with what you described.

[MarcelWaldvogel]

Great suggestion, putting it on the main page is definitely more user friendly than having it in the settings dialog.

Trying to reduce the number of buttons and keeping drop-down menus to a minimum, I am currently in undecided between the following two options:

1. A button "Copy URL With Access Code"
2. A checkmark "Include Access Code" which would change the URL.
   Of course, these buttons would only appear if the room had an access code at all.

I have a slight preference towards 2, as what would be copied would be visible to the user, even though it required a second click for that (and it would eliminate the need for the URL technical term). Copying the access code itself would still be possible from the room settings dialog. Would this be considered inconvenient?

[MarcelWaldvogel]

SecureRandom does have random_number, which obviates the need for choose. It is implemented in C, so not visible in the Ruby source. So uid_chunk could be implemented as follows:

require 'securerandom'

def uid_chunk
  charset = ("a".."z").to_a - %w(b i l o s) + ("2".."9").to_a - %w(5 8)
  (0...3).map { charset.to_a[SecureRandom.random_number(charset.size)] }.join
end

[lkiesow]

A checkmark "Include Access Code" which would change the URL.

You would put the checkmark where I put the additional button?

[MarcelWaldvogel]

You would put the checkmark where I put the additional button?

Yes.

[lkiesow]

I could imagine that could work.

[farhatahmad]

Coming back to this, we had some talks internally about how the room uid should be generated, and we eventually decided on making it configurable. Through the admin interface, an admin will be able to specify the "format" of their uids. There are some users who like the more friendly/short ids and there are some who want completely random, unguessable ids.

I'll have some more information when I actually implement it and send a PR for it

[lkiesow]

@farhatahmad, sounds reasonable but can we make the more secure option the default?

[MarcelWaldvogel]

I am in favor of as few configuration options as possible when it comes to security (and, in favor of security by default, so I second @lkiesow's motion).

I would like to understand why room UIDs should be insecure. I'll start with a few use cases, and maybe you can extend this, @farhatahmad:

• The user receives a link by electronic means (mail, IM, …) and clicks on the link (according to my experience, this is the vast majority of use cases):
  
  
  
  • It is not typed in, length/complexity/memorability of the string is irrelevant
  
  
  • Friendliness may be an issue, as to suggest a more welcoming impression
  
  

• The user has to type it in. I think this is the very rare event, possibly caused by air gaps, paranoia, or having a secretary printing out all email and then deleting it from the inbox:

  • It is typed in, so length/complexity/memorability is of prime concern
  • Friendliness may be an issue to help memorability and reducing typos

  In the first two cases, security is an issue, so I doubt that these environments/users would want to go with substandard security. In the third case, the secretary sets up the conference and all hope is lost anyway.

Therefore, I see very little reason to go for low entropy (and, therefore, easy enumeration by a Zoombomber/B⁴omber or snooper). However, I would understand to have the option of readable strings akin to what Jitsi Meet uses (e.g., HomeTablesMoveFerociously or ForwardIntegrationsInvadeOverall).

Jitsi Meet gives about 40 bits of entropy for the transient rooms (i.e., no way to probe ahead of time for validity) while the current BBB scheme gives about 28 bits, assuming the first few chars of a username are known. As valid room names in BBB can be automatically probed ahead of time, the chances of getting at a session is much higher, so BBB needs more entropy to achieve Jitsi Meet-level room name security.

If indeed friendliness of the room name is a requirement, I propose the following:

• The default is 4 triplets, without the first triplet being the start of the username (57 bits)
• Users with appropriate privileges granted by the admin can create Jitsi-Meet-like room names (which are, btw. case-insensitive, presumably for usability). When creating such a room, the user is recommended to add an access code to raise this from 40 bits.
• Additionally, a rate-limiting/blacklisting mechanism against room name enumeration is built into BBB (or prepackaged/preconfigured, e.g. with fail2ban)

[farhatahmad]

The initial change to the 4 triplets was reverted in #1670. We had some more talks internally and kind of decided against this for a couple reasons. We're currently stuck in the middle of 2 worlds with respect to Greenlight: perfect security and friendly user experience.

While increasing the room-uid length may seem to provide better security, I would argue that it actually does not do much.
1- The majority of the times that I've seen, conference bombing happens because someone who is allowed to join the conference shares the meeting link with someone else
2- Most standard firewalls/deployment providers should be able to capture people attempting to brute force and handle them appropriately

To better combat the issues you listed above, I would argue that using the site setting "Require Authentication to join rooms" and the room setting "Require moderator approval" are 2 much more reliable methods to combat the issues provided with the relatively short uid.

[MarcelWaldvogel]

You mention the trade-off between security and user experience. I think we disagree on both. When it comes to security, I believe in laying out the reasons. So far, my questions aiming at understanding the reasons for your decisions Therefore, let me try and understand your arguments by asking some questions and hoping you can improve my understanding. So far, I

User experience would be worse with 4 triplets

How is user experience deteriorated by having

1. a URL which no longer includes the first three characters of the user name (even though most users probably think they are somewhat random), or
2. a URL which is already 3 random-looking triplets long changed into one with 4 triplets? (This probably implies that the user has to type it in, instead of clicking/copy-pasting. Why is this a common action?)

More redundancy provides no security benefit

1- The majority of the times that I've seen, conference bombing happens because someone who is allowed to join the conference shares the meeting link with someone else

I have no data on this. But with the current ~28 bits, a site with ~100 active sessions requires only about 2 million probes to get in. If a site has 1 million active sessions, an attacker is in a session with ~200 probes. (Again, not including the randomness of the user name here; this will increase the numbers, depending on factors which are not easily abstracted.)

2- Most standard firewalls/deployment providers should be able to capture people attempting to brute force and handle them appropriately

Yes, most professional setup personnel should be able to implement this. But only few of them will think about it. And BBB is getting a lot of deployment at smaller sites, which means people with minimal knowledge (especially security) and/or time to deal with all the nitty-gritty details. Also, I doubt that "standard firewalls" will prevent scanning out of the box.

So, in line with the security by default paradigm, BBB should be able to protect itself against scanning, at least somewhat. In my opinion, this means (1) increasing room URL entropy and/or (2) active measurements against scanning. (I will move this part of the discussion to a separate issue.)

The value of the access code?

To get back to the argument "if room URLs are misused, it has been the user sharing the information": Why is there a need for access codes?

Authentication/approval settings

"Require Authentication to join rooms" and "Require moderator approval" are two important factors, indeed. But for many sites, they will not be turned on, because of UX issues:

1. Globally requiring authentication makes it hard to impossible for guests to join a room, depending on site settings. So in addition to the per-site setting, there should also be a per-room setting with that effect.
2. Requring approval is on a per-session basis only, not on a per-room basis.

When indeed authentication and approval settings should be the main access control mechanisms, they will need to tie in smoothly into the users' workflows. I'll gladly participate in that discussion, if that is something that you consider working toward.

[farhatahmad]

How is user experience deteriorated by having

This was in regards to making it configurable. Based on some of our users, they like the "friendly" first 3 characters as it seems to be a good mix of random and friendly urls for rooms. We will most likely add the 4 triplet, but leaving the current format intact

Why is there a need for access codes?

Room Access Codes does not prevent conferences from get BBB bombed, but rather it prevents a first layer of protection against random guests (or signed in users) from joining a room. As I've mentioned, it's only as secure as the people who join the room make it.

As for the "Require Auth..." I believe there was an issue open to make it a room setting and not a site setting.

[MarcelWaldvogel]

Trying to classify the use cases for rooms and their access rights (I know it's getting off-topic, but I am not aware of a better place to start the brainstorming):

1. Workgroup/coffee-room meetings, flat hierarchy: Everyone has an account and there is enough social binding so those limited few will not abuse their powers in a room unduly.
2. Workgroup/school meetings, clear hierarchy: Everyone has an account, but someone is in control of managing rights during a meeting.
3. One-on-one meeting, internal participants only: Same as flat hierarchy workgroup above.
4. One-on-one meeting with external participant: Internal user controls access.
5. Group meetings among internal/external participants: Internal user(s) control access.
6. Social meeting among internal/external participants: Social floor control works.

Trying to put this into a rights matrix, it might be a good idea to have the following possibilities:

• Room owner is always moderator (as we have now)
• Room owner can invite other registered users (as we have now)
• Room owner can limit room to those invited
• Room owner can allow uninvited ones to knock (as we have now)
• Room owner can grant moderator access to those invited

This would reduce the exposure of sensitive rooms and contribute to the goal of this issue. But it probably is a bigger change.

[farhatahmad]

Fixed in 2.7 (please open another issue if there is something I missed)