Closed holzhannes closed 2 years ago
Would increasing the length of the URL help you as well? One of the reasons for access codes is to add entropy, so uninvited joins to a room are hard. Making the URL harder to guess might be an alternative to solve the problem behind your request.
Right now, the first three digits of a GreenLight room name are determined by the user name and the remaining two base-36 triplets provide at most 31.02 bits of entropy.
I think for users it's better to have a short room-name and a seperate pin instead of a long and complex roomname. (Maybe you remember transition from Kontonummer and Bankleitzahl to IBAN. :-D )
And yes: Room names without first three letters of host name would be better.
Would increasing the length of the URL help you as well? One of the reasons for access codes is to add entropy, so uninvited joins to a room are hard. Making the URL harder to guess might be an alternative to solve the problem behind your request.
Right now, the first three digits of a GreenLight room name are determined by the user name and the remaining two base-36 triplets provide at most 31.02 bits of entropy.
Thank you @MarcelWaldvogel for your Idea and thanks @Sea444 I share your opinion for short room links without user indication within the link. From my point of view it is an important security setting to force codes for rooms maybe also by a setting within the user roles. Just extending the length would not help in the end if you don't trust the channel where the link is shared or you can't control how long a room will exist. If you have a policy to share codes on a second channel because you don't trust the first channel longer links would not help as well.
@holzhannes If you don't trust the channel where you share the link, you need a separate channel for the access code anyway. Why not use that channel to send the entire link instead?
(Yes, I know that this might require manually typing more, but I would claim that most users which would like to communicate in a video conference have a trustworthy channel from where they can click a link. Making it more complicated for the rest of us is not an option, IMHO. See e.g. the access code URL patch #1331, which increases the entropy by another 20 bits while still being as easy to use for most users, i.e., just a single click on the URL.)
I just submitted a pull request (#1451) which makes the room URLs much less guessable.
I believe that URLs will be communicated over digital media, thus the invitee just has to click on it (or, in the worst case, copy/paste it). So users rarely have to type it, which is in contrast to the IBAN example above.
I also believe that most of these channels to communicate the URL are at least trustworthy enough to communicate the topic of the discussion and a (partial) list of participants. So, basic security is given, and the impact of a URL snooper is small (and can be essentially eliminated by requiring moderator approval). If this really does not work out, part of the room URL can be passed along a different channel.
If you disagree, I would be interested in your usage scenarios.
I would also appreciate the possibility to have the option to force access codes for every user (or user groups). The current workaround is to tweak the room.js, but this needs maintenance as that file can change with updates.
Hi Robertbln,
I would also appreciate the possibility to have the option to force access codes for every user (or user groups). The current workaround is to tweak the room.js, but this needs maintenance as that file can change with updates.
Is it permitted to post the tweak here, until it's added to the general code? Those who have Greenlight running in custom mode can add it locally until its part of the overall code. Would be great.
yes, you can add it here. My workaround was just to add generateAccessCode() in the room.js, then it's on by default.
old:
// Only run on room pages.
if (controller == "rooms" && action == "show"){
// Display and update all fields related to creating a room in the createRoomModal
$("#create-room-block").click(function(){
showCreateRoom(this)
})
checkIfAutoJoin()
}
new:
// Only run on room pages.
if (controller == "rooms" && action == "show"){
// Display and update all fields related to creating a room in the createRoomModal
$("#create-room-block").click(function(){
showCreateRoom(this)
generateAccessCode()
})
checkIfAutoJoin()
}
yes, you can add it here. My workaround was just to add generateAccessCode() in the room.js, then it's on by default.
old:
// Only run on room pages. if (controller == "rooms" && action == "show"){ // Display and update all fields related to creating a room in the createRoomModal $("#create-room-block").click(function(){ showCreateRoom(this) }) checkIfAutoJoin() }
new:
// Only run on room pages. if (controller == "rooms" && action == "show"){ // Display and update all fields related to creating a room in the createRoomModal $("#create-room-block").click(function(){ showCreateRoom(this) generateAccessCode() }) checkIfAutoJoin() }
Thank you!! that is a very simple change. This change works when creating a new rooms.
Doesn't work after users login for the 1st time (code on on default home room will not be set). Maybe this is something I can figure out?
Can we somehow boost that feature? I would try to let this sponsor - please contact me, if you are interested and can guarentee to put that into the core of greenlight.
@ffdixon
Can we somehow boost that feature? I would try to let this sponsor - please contact me, if you are interested and can guarentee to put that into the core of greenlight.
IMHO not having the option to enforce the usage of room codes make greenlight less interesting for enterprises.
We appreciate the feedback and feature suggestion.
Is there a way/process to sponsor that feature?
It’s getting worse ...
@kaystrobach Can you translate the screenshots in this twitter thread into English and give us the gist of what is happening.
Basically the pupils are organizing in groups of 50 to 100 people, which “storm” rooms with or without codes or without moderator authorization and disturb the classes.
They are using different strategies to compromise the meetings.
We found hundreds of links to rooms of our infrastructure, partly posted by the pupils, partly posted by the school authorities themselves.
Our current counter measure is to enforce the waiting room option.
We had some serious stuff going on, which we had to hand over to the police.
At the end i would love to see defaults for rooms settings and “preconfigured safe combinations of options”
As students are sharing the link as well as the access code and - in our cases - even adding names of real students of this class (so the intruder can use these names to log in) the teacher can't distinguish between his own students and foreign intruders. Even the waiting room enforcement isn't helping against that.
The only working countermeasure is not using greenlight at all but switching to opening the BBB sessions via LTI access in our LMS. This problem is not a security issue of greenlight, this is active sabotage by the invited participants of a BBB session. So "by design" there aren't any possibilities to solve this problem by configuring/improving greenlight IMHO. Every access system based on a shared secret will fail when the secret gets published, of course.
As students are sharing the link as well as the access code and - in our cases - even adding names of real students of this class
one option would be to have one time codes, which are valid for some minutes and one check in only. But this is imho too complex for most school scenarios.
another one would be to allow students to have accounts in greenlight and use the only authenticated users option. Even that seems to be too complicated for some teachers.
for now we use the waiting rooms to ensure, that the class will not be disturbed once all pupils are in.
another one would be to allow students to have accounts in greenlight and use the only authenticated users option. Even that seems to be too complicated for some teachers.
This is the only way to secure the rooms correctly. As we've seen in BigBlueButton and other video conferencing systems, access codes don't stop people from joining the room as students will openly share the link and the access code to any room. Only authenticated users is the correct way to go here, but I'm not quite sure why its "too complicated". You simply hook up authentication, set up the students rule so that they can't create rooms, and then force all students to sign in before joining a room
"too complicated" - in my case - means that you usually don't want your students to have accounts at all, because ... well because you don't want this ("I forgot my password", "Where do I have to login" etc.). In many cases there isn't even an authentication service like a LDAP directory or something to bind to, so you would have to set up accounts for all the students in greenlight.
But you're completely right, it's the only option besides not using greenlight at all, but e. g. moodle plugin or LTI access.
https://gdpr-info.eu/art-25-gdpr/ All settings which improve data protection must be enabled by daufault. This is european regulation. The user should not just have the option to create an access code, the code must be the default setting. This also also includes the other rooms settings.
if there is interest, i can share our patch solution to enforce room codes with just an js file and some nginx settings.
if there is interest, i can share our patch solution to enforce room codes with just an js file and some nginx settings.
YES! plz share!
/var/www/html/enforceRoomcode.js
$(document).ready(function() {
$('input[type=submit].create-room-button').on('click', function(event) {
if($('#room_access_code').val() == '') {
event.preventDefault();
$('#room_access_code').prop('required', true);
alert("Generieren Sie bitte einen Raumzugangscode!");
return false;
}
});
if (!$('#copy-access').length){
// $('.button_to').parent().html("<div class='alert alert-danger'>Setzen Sie einen Zugangscode! Sonst kann die Konferenz nicht gestartet werden</div>");
$('.pt-7').after(
"<div class='alert alert-danger'>Setzen Sie einen Raumzugangscode! Die Option finden Sie hinter den drei Punkten am Raumname, dann der Menüpunkt Raumeinstellungen.<br><a href='https://docs.schullogin.de/20-Werkzeuge/30-BigBlueButton/15-Sicherheitseinstellungen/Index.html#nutzer-die-die-links-an-dritte-weitergeben' target='_blank'>Weitere Informationen finden Sie in der Dokumentation.</a></div>"
);
}
});
In the nginx server section provided by bbb you need to add the following to be able to access the js file
location = /enforceRoomcode.js {
root /var/www/html/;
}
and this to ensure, that the file is appended in the html code of greenlight
sub_filter '<!-- Global javascript variables and helpers. -->'
'<!-- Global javascript variables and helpers. -->
<style type="text/css">
.wrapper > .sessions, a.px-3:nth-child(2) {display:none}
[data-room-access-code=""] > ::before {content: "Bitte setzen sie den Zugangscode!"; font-weight: bold; padding: 10px;}
[data-room-access-code=""] {border-color: red!important; background-color: #ff000026!important;}
</style>';
sub_filter '</body>'
'<script src="/enforceRoomcode.js" type="text/javascript"></script></body>';
I have not translated the strings in the JS code as we only need the german version.
Short summary of english version
Generieren Sie bitte einen Raumzugangscode!
--> Create room code!
Setzen Sie einen Raumzugangscode! Die Option finden Sie hinter den drei Punkten am Raumname, dann der Menüpunkt Raumeinstellungen.
--> Create room code, it's accessable via the room options.
One important note - this only works in the client - so the client needs to have JS enabled! Otherwise you can still create rooms without code. Anyway our stats show, that nearly no normal teacher is capable of going around this restriction, so this is sufficient for us.
Hello! Unfortunately, we will not be able to devote time into this feature/enhancement request at the moment due to our attention being directed towards Greenlight v3! If this is something you believe that will be beneficial to v3, then we encourage you to please re-create this request once v3 is up and running.
To find out more information on Greenlight v3, please click the following link: https://groups.google.com/g/bigbluebutton-dev/c/1nG-k_iTHjo
Thanks for your continued support!
Due to security of the system it would be very nice if an admin could force access codes for all rooms or a group of users.