Use Cases and Ideas for secure Room Codes

[sagefreeman]

Room Codes was recently removed from Hubs to ensure security and privacy standards. This discussion aims to capture use cases and ideas to help reintroduce a similar feature that is secure by default.

Below are some starters...

Use Case: directing large groups of users (eg, students, audience) on VR head sets into shared rooms in Hubs.
Use Case: directing small groups of users (eg, friends, family) on VR head sets into shared rooms in Hubs.

Idea: could Room Codes be tucked away under Room Settings to discourage abuse?
Idea: could room codes be enabled for signed in users only?
Idea: could room codes be enabled for Hubs Cloud instances that are configured to require accounts for any room entry?

Note: Enter on Device codes are still available but should not be shared with multiple users and timeout quickly.

[brianpeiris]

Thanks for starting this discussion.

Idea: could Room Codes be tucked away under Room Settings to discourage abuse?

I don't think this particular idea is viable from a security perspective. We're not concerned with regular users abusing the feature. We're concerned with malicious users. Simply hiding the feature behind another screen will not deter attacks, and the important part is the backend mechanism anyway, not the UI.

Aside from re-introducing a similar feature (with security concerns addressed), the community might find it useful to know that short links still work with the room ID. For example, hub.link/ro0miDs, using the 7-character alphanumeric code, will still redirect to the full URL. This also applies to the short domain used on a Hubs Cloud instance.

Another potential idea might be to couple a room code with a password, though that might defeat the purpose of the feature if the main goal is to reduce the effort in typing things out. Arguably, you might as well use the room ID and short link instead, since it is only 7 characters. To make things a easier, we could have hub.link (or the equivalent on a Hubs Cloud instance) let you enter a room ID in a normal text input. That would improve UX slightly, since you could then bookmark hub.link and only have to enter the room ID, instead of the whole short link.

Another option, outside Hubs, is to use a different sharing mechanism for group scenarios, such as QR Codes, email, shared chat, etc. That would allow you to maintain privacy and provide ease of access by other means.

[profhupe]

Thank you @sagefreeman for starting this thread and @brianpeiris for being so responsive. Brian, I like the idea of having hub.link let users enter the room ID.

Currently, I have hub.link bookmarked on all of my oculus headsets (classroom set of 20). Students then only have to navigate to the bookmarked page and enter the 7 digit room code.

[rawnsley]

I think Sage's suggestion of limiting short code entry to logged in users makes sense as it gives you a unique key to rate limit against. However, an attacker could create 10,000 accounts and start war dialing for codes with a 1% chance of getting a specific room on the first try and a higher chance of getting any room.

The addition of a captcha to the room code entry dialog might help if captchas still work, but it does add friction.

Brian's suggestion of a third party service makes sense, especially if it's something with it's own authentication like Teams.

For colocated users there are services like https://hmd.link which rely on devices having the same public IP address. This is common for devices on the same LAN, but not for mobiles using a cellular connection.

[wmurphyrd]

This was one of the most differentiating features of Hubs for me. I could text someone to join me at immers.link with code 123456, and then they could choose to join there on phone or easily enter the code on PC or VR, no matter their technical skill.

A base-62 room id string is not in the ballpark in term of usability.

Now that it is mitigated, could you disclose the details of the attack vector so that we can propose alternatives?

For a simple brute-force, adding a 1 second delay in the server response would be imperceptible to users but would push the cracking time over 10 days. Combined with a global API rate limit (which may not be feasible for something as high traffic as hubs.mozilla.com, but would be totally fine for most Hubs Clouds), the attack time could be stretched out so long as to be futile.

[brianpeiris]

Just to make sure I didn't misunderstand, did you have a particular implementation of rate-limiting in mind that would cover the case of an attacker using multiple IP addresses, and that would work with multiple app servers, or were you suggesting a rate limit with a global queue?

Also, is it fair to say that you value this feature enough, that you would sacrifice some security on your instance?

[profhupe]

One other idea. Could room codes be active for a limited amount of time (a few minutes) to allow everyone time to join?

On Tue, Mar 1, 2022 at 1:16 PM Will Murphy ***@***.***> wrote: This was one of the most differentiating features of Hubs for me. I could text someone to join me at immers.link with code 123456, and then they could choose to join there on phone or easily enter the code on PC or VR, no matter their technical skill. A base-62 room id string is not in the ballpark in term of usability. Now that it is mitigated, could you disclose the details of the attack vector so that we can propose alternatives? For a simple brute-force, adding a 1 second delay in the server response would be imperceptible to users but would push the cracking time over 10 days. Combined with a global API rate limit (which may not be feasible for something as high traffic as hubs.mozilla.com, but would be totally fine for most Hubs Clouds), the attack time could be stretched out so long as to be futile. —

-- edited to scrub personal info. Please take care with email signatures coming through to github. -Matt Cool

[yakyouk]

In this scenario, would codes be generated on demand only? This would then be similar to @Charlesc22 's idea where a room owner can generate and share a code for their room.

• room owner generates an entry code and shares it
• code expires after N minutes and is not replaced until room owner generates a new one
  Code length and validity duration could be configurable in admin panel, with some restriction (eg min length: 6, max duration: 60min)

[brianpeiris]

While this would certainly be better than the previous implementation, it would technically still be vulnerable to scanning, since it doesn't address the vector where an attacker could scan for a very large number of codes in a short period using many IP addresses (assuming a it's just 1 million 6-digit codes).

[brianpeiris]

@wmurphyrd As profhupe mentioned would you be satisfied if we allowed entering room ids on on the link page?

[wmurphyrd]

No, I don't think the room ids are practical at all. What are they base-62 x 7? That's way more information than a person can hold in their head at a time and then you've got look-alike characters to worry about. Imagine trying to speak one of these to a group of people

[brianpeiris]

They are base-64 with similar characters (O01IL) removed. Thanks for clarifying your use case.

[brianpeiris]

To answer the question about the attack vector; Obviously any solution we use would have to be resilient to simple fuzzing attacks, where a single machine just bombards the endpoint with a million room codes as fast as possible. The situation is complicated by the fact that we also have to consider Hubs Cloud instances with multiple app servers. It would not be sufficient to rate limit per server, per IP, since the rate limit would be decimated by the number of app servers you have running in your instance.

Additionally, the solution would have to be resilient to attacks that use many attacking machines, or IP addresses. This kind of attack can come from a botnet, or more easily from a service that runs serverless functions at scale from multiple IP addresses. In theory the endpoint could be attacked simultaneously from thousands of different IP addresses, even up to a million IP addresses if the attacker were determined enough, in which case you would not be able to distinguish an attack from normal usage, unless you monitored the endpoint based on traffic. In order for a ratelimit to be effective for a multi-server setup, it would have to be applied globally across all servers, and even then you would have to queue requests, not simply delay them, in order to account for attacks from multiple IP addresses. Those are the constraints and pitfalls we have to consider. I'd be happy to hear if the community has other solutions.

We attempted to mitigate with a simple rate limit (per IP, per server) and we then attempted to mitigate with a fail2ban solution (again per IP, per server). These mitigations were not sufficient to protect against attacks from multiple IP addresses. Our goal with this change was to remove the attack vector so that users wouldn't continue to be vulnerable to it.

Lastly, to the question about allowing Hubs Cloud administrators to opt-in to this feature. This is more of a product-level decision than a technical one. Should we allow users and administrators, to expose their rooms in such a way? Will users be savvy enough to understand the concerns an make their own decision? Can we message the security concerns clearly enough? Perhaps if a Hubs Cloud instance was secured in some other way to begin with, like a global password protection, or required sign-ins, it would be reasonable to allow 6-digit room codes, but would the added protection break the usability for the use cases that all of you have in mind?

[yakyouk]

Having an input field for the room ID seems like a good alternative to me but I think the biggest issue for usability is case sensitivity. Ideally you'd have a code that's all-lowercase + numbers (minus similar chars). To match base64*7 difficulty, room ID would need to be 8 chars longs instead of 7, which is not a big stretch.
Or use that 8-char as the room entry code instead of the 6-digit code.
Adding a password doesn't make a lot of sense to me, I'd rather have a single long-ish code to enter than a code+password. It would also seem redundant with the invite id for rooms in invite mode.
Other than that, as mentioned earlier, having very-short-lived 6~8 digit-long numeric codes should work as well.

[brianpeiris]

Thanks for the input. Our current room ID is 7 characters, alpha-numeric, including capitals, with Il10O removed. That gives us 57 ^ 7, which is 1.95 trillion codes.

If we used 8-character, lower-case alpha-numerics, with l10 removed would give you 1.40 trillion codes, which is close enough. Codes would look like 4pir k67s.

However, if you cared about sharing codes verbally, you might want to remove sound-alike characters as well, so you might exclude l10bpmn, in which case you'd have 500 billion codes at 8 characters. We'd have to think about whether 500 billion is sufficiently secure. It may be. At 9 characters it would be 14.5 trillion codes, which might look like gsj 795 3ta

Still, this might not satisfy those who really would rather use 6 digits instead for ultimate ease of sharing, especially in verbal scenarios.

---

Sample code for playing with the parameters:

var excluded = /[A-Zl10bpmn]/g;
var chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'.replace(excluded, '');
var codeLength = 9;
var totalCodes = (chars.length ** codeLength).toLocaleString();

var code = Array.from({length: codeLength}).map(() => chars[Math.floor(Math.random() * chars.length)]);
code.splice(3, 0, ' ');
code.splice(7, 0, ' ');

console.log(JSON.stringify({ chars, codeLength, totalCodes, formattedCode: code.join('') }, null, 2))

/*
 {
  "chars": "acdefghijkoqrstuvwxyz23456789",
  "codeLength": 9,
  "totalCodes": "14,507,145,975,869",
  "formattedCode": "dtf sxh vej"
}
*/

[yakyouk]

To exclude a few less characters maybe keep one character for each pair of ambiguous characters, then map l to 1 and O to 0.
@wmurphyrd @fonefen how would a 8- or 9-char lower-case letters + digits code compare with the original 6 digits?

[fonefen]

I want to express my discomfort for removing such an important functionality for the community in such a drastic way.
Removing the functionality to access rooms by code is a serious problem for our projects. The advantage of this system is to simplify the access of anyone to a virtual room (we have a project for the educational sector) from VR glasses. Since it is complex to write a lot of code in the browser of the glasses, the code is perfect.

We need to find a way to simplify this step.
In another VR project I worked on, we reconvert the numbers into a pattern of colours or shapes, it is more difficult to retain, but it makes it very difficult for the bot. It is also easy to implement, we would only have to convert the numbers into colours or shapes and they would be able to activate the service.

I hope we will have a solution soon, right now my startup depends on this functionality a lot. I trust in this great Mozilla hub team.

[yakyouk]

The feature was removed because it allowed running room discovery by brute-force testing 6-digit codes. This type of attack isn't typically done in a browser but rather by directly fetching the underlying endpoints, so replacing numbers by shapes won't make an attack any harder

[fonefen]

I understand. But this problem will also be experienced by applications like kahoot! or others of the same type. Has anyone analysed the actual security impact vs. usefulness for VR use before removing the functionality? A feature should not be removed for the whole community without a solution first. I think this is a serious mistake.

[Charlesc22]

I tend to agree with @fonefen here. Systematically removing a very useful function because it could possibly be abused does not seem like the right solution. I'm not a security expert, but I would think there are other methods to identify bad actors and block them rather than remove the functionality entirely.
Perhaps have the functionality off by default in a Hubs Cloud instance, but offer the option to turn it on in the admin. You could offer a warning and explanation in the admin when you turn it on so the Admin is aware of the possible issues.

[Charlesc22]

one suggestion is that you could also have it controlled by the owner/moderator of the room. So the function is off whenever the room is not being used, but when a moderator enters a room for an event or a meeting, they could turn it on, and then it gets turned off automatically when everyone leaves the room

[dvdsmthdvd]

This is a good suggestion. I'm just now discovering this new issue, and while I (really) appreciate the Hubs team identifying this security risk, it's going to be a huge challenge for our projects that rely on Hubs Cloud in VR.

[emclaren]

Hi folks, and thank you so much to Sage for starting this discussion so we can compile your feedback in one place. We really appreciate hearing your thoughts on this issue. We definitely hear your concerns, and this decision was not one we took lightly. Ultimately, we felt that the security risk was too significant for us to leave as is in Hubs at this time. We are keeping an eye on your suggestions and are weighing the possibilities from a product standpoint (e.g: offering this as an "admin option"). Please keep continuing to add suggestions as we are reviewing and learning from them.

[kirkglpro]

Ideal to remove as a baseline build, however, for custom projects it could be allowed considering the custom build developers can manage it as a custom requirement. The admin option is suitable.

[kirkglpro]

The 'Have a room code?' is still present on the home page.

[fonefen]

We have a solution to this problem? several options have already been presented. Our project is currently in serious trouble without this functionality. Is there any time frame to solve it? Thanks Team.

[fonefen]

Greetings to all. Is there any way to activate the code function in my custom project while working out ideas? It's been a nightmare for us to solve this problem. We have hybrid classes in our project and without code it is a very costly task for our clients. Can anyone help us? Sorry it sounds a bit desperate, but we are. We have a service in dozens of schools (we never had problems with the code at security level) and right now teachers are discarding to give classes with VR because of the difficulty that exists without the code option. We have tried the HMD.link option but not all schools are solving the problem. I hope someone can help us to retain the project. Thank you.

[dvdsmthdvd]

Agreed that this kind of seemingly small friction point becomes much bigger in educational settings. In addition to a project in progress that relies on easy access to room codes in VR, I was hoping to use Hubs Cloud in the classroom more. This might prevent me from doing so. I currently have a custom Clouds build and haven't updated to the latest version, but I'm not sure how much longer I can hold off. Hoping there's a more elegant solution coming soon!

[elmau]

I have an idea but I don't know if it is better: If the problem was a user scanning for number codes, how about using sets of 24 icons where you have to put 5 in certain order as a password? Then those icons could be translated to unicode, creating a long password. Example: U+0267DU+0266CU+0265CU+0265AU+0262F Could that work?

[Doginal]

I would suggest instead of removing the lock code, we should add a delay to the number of times it can be entered.

If 5 bad codes, it should lock out the user for 5 mins and increase as the number of bad attempts happen. In my mind 5 bad codes should equal a 5 min ban then the next 5 would be 15 and keep upping it to reduce the chance someone will even try to brute-force it.