Passcode to join zipcall

[harsha20599]

Since the URLs are just a gate pass for the video call, there might be a chance of getting intruders into the call with a simple brute force.

Users feel more secure if we have some passcode or approval from the creator to join into call.

[Chaphasilor]

We could add this as an optional setting. I'm thinking of a 'lockdown' button that prompts the host for a password when they activate it and then every new user to join has to enter the password?

[bdlb77]

@Chaphasilor, I'd be a FTC for this repo, but if you think it's a good first issue to start with, I'd love to give it a shot!

[Chaphasilor]

@bdlb77 that would be awesome!

take your time getting to know the repo and code, and if you feel confident you can implement this in a secure way somehow, just give it a shot and open a PR :D

[bdlb77]

@Chaphasilor, I'm thinking of an approach similar to how Zoom does it:

A user enables the the "lockdown" toggle / button and it will generate a URL with a hashed token/password attacked to it at the end:
https://zipcall.io/join/ChatName?token=xxxxx-xxxx-xxxx
The user will also be prompted with this token as a chance to copy it to clipboard and they can pass it manually to others :)

[ttntm]

+1 for this one, would be nice to have.

Maybe it could be helpful to have a look at how Jitsi (https://github.com/jitsi/jitsi-meet) implemented their "password protect meeting from within" feature.

[Chaphasilor]

@bdlb77 sorry for the late reply, I already replied in my head 🙄

The token-based idea is okay, I'd say, but this way users will have to copy and paste the token, instead of just telling the other participant the password. I know this is only an issue once lockdown is activated while the call is already going and a new user want's to join, but it's still an issue.

Imagine the following scenario:
A group of friends want to start a call using Zipcall and one of them sets up the call. He then pastes the link into a group chat. Some of his friends join through the link, then he enables lockdown mode. But some of his friends weren't ready yet and try to join later, which doesn't work without the token.

I think given that Zipcall isn't intended for business use, we could use a mix of token and password, i.e. a short token that is easy to remember (only numbers, or only hex, max. 8 characters). That should be secure enough but also easy to share.

Also, keep in mind that you'll need to update the call link and show it with a snackbar once lockdown mode is enabled :)

All in all your idea is good, just try to keep the token as simple as possible!

[bdlb77]

@Chaphasilor
I guess it depends on how secure the call should be:

1. Make the URL more unique with a "passsword"

• zipcall.io/join/ChatRoom183x032-143d9
• All this will do is just make

2. A Password token

• zipcall.io/join/ChatRoom?password=183x032
• Now the tricky part is authenticating this password to check if its valid, but if there is no state on the server, there won't be a way to check to see what is the valid password for that call.

The first option is just creating a more unique URL and doesn't really do much of a justified "locked down call"

For the 2nd option, If WebRTC creates a peer-2-peer stream... The password can be stored in the metadata for a user and streamed to an incoming user who wants to join.. and if those passwords match then they could be authenticated and fully join the call.. Or something along these lines... Maybe I'm missing something that would make this a little easier? haha

[Chaphasilor]

@bdlb77 yeah, I think the second option would be the way to go here.
Also, as you already stated, we'd have to do some serverless auth using WebRTC.

Maybe we could use the Zipcall server to check the pass token though, for example by requesting all currently connected users to send the current password and check if it matches the one provided by the new client?
This should be easier to implement than a fully serverless approach.

For a fully serverless solution you'd need every call participant to check if the new client's pass token matches their own one and only open a WebRTC connection if it does. I imagine this to be a bit more complex.

But I guess you should just try out both approaches, maybe we've missed something :D

[ianramzy]

Using the server for authentication would be the better approach here.

[bdlb77]

@ianramzy you're referring to a different approach than the 2nd option correct?

The concern I have with using the server for authentication is that state would need to be introduced to persist a password that belongs to a video call. I think Node.js has this functionality to support in-memory storage (basic example: https://stackoverflow.com/questions/2219333/nodejs-in-memory-storage). There'd need to be some in-memory cache on server-side to persist Room Names and Passwords. Doesn't seem too bad to implement :)
@ianramzy @Chaphasilor Would you prefer this approach over a peer-to-peer authentication approach?

[Chaphasilor]

@bdlb77 well my first idea is using the server, maybe @ianramzy meant that?

If not, we'll have to be careful with server state, because Heroku will wipe all data and re-setup the server regularly.
I also dislike the idea of using a database for this.

[bdlb77]

@Chaphasilor so: a User joins and provides a password, in the server it pulls down the password of the Host by webRTC data (I don't know how else you'd query the Host's client without some other reference to the Host), and you check it in the server.

I'm not sure I understand fully that Heroku will wipe all data regularly. Will that happen while a connection is active to the call? I'd imagine this approach would use a Redis store

I'll work two of these examples and maybe it'll help give further light over which approach is more worthwhile.

1. I'll do your suggestion of comparing password from joining User to that of the Host (which is pulled down from their client)
2. I'll try it out with an in-memory storage solution

I should be able to show something in the next couple of days :)

[Chaphasilor]

@bdlb77 yep, something like that :D

Heroku will regularly 'move' the server, i.e. clone the repo to a new virtual server, start it and then erase the old server files. This means you can't save anything to the fs and server state will reset regularly. I'm not sure how connections influence this and I also don't know if the Zipcall server constantly keeps the connection alive, you'd have to check with the Heroku docs :)

I'm looking forward to what you come up with! <3

[jdforsythe]

Is it simpler to just have the user who created the chat approve new users who are trying to join, no password needed?

[pkesavap]

Is it simpler to just have the user who created the chat approve new users who are trying to join, no password needed?

since there is no user authentication, I don't think this would be a good idea, there are ways to bypass , something like the same name, etc.

[jeanpeche]

do you know how the Whereby solution works? with locked room, and the owner of the room accept (or not) people to come in..

[GhamdanNshwan]

yes