3

I'm having a debate with a coworker right now about how to design an invitation system. The idea is that the mobile app will be able to send an invitation link to, say, a Whatsapp group, and people from that group will be able to use the link to join our system and be automatically enrolled into a group on our system. The coworker suggests the link format be along the lines of:

https://www.ourdomain.com/Register?groupId=12345

I said that this was insecure because someone could just change the group ID and register with our system (which is marketed as, amongst other things, 'secure'), having the system join them into any group they can guess the ID for. This system is going to be used by medical professionals. I suggested that the "group ID" should be encrypted, and he responded that there's no point because someone could just reverse engineer the app and generate their own encrypted group ID anyway.

I then suggested using a server-generated ID for the invitation ID, and storing the group ID in which to enrol the user upon registration in the server's database, to which he responded that that too could be hacked, and that it would just be harder.

What's the best practice for this sort of "invite link" in terms of security? It seems to me that the coworker has a very blase attitude towards things, and that whilst technically the system could be hacked, it's still worth making it harder to hack.

  • 3
    This is the same problem Zoom had. Have you looked at their solution to the problem? – schroeder Sep 23 at 14:17
  • 2
    "It seems to me that the coworker has a very blase attitude towards things, and that whilst technically the system could be hacked, it's still worth making it harder to hack." - that's the right mindset. Security will almost never needs to be a 100% solution, the main point is that the cost of hacking the system will be much higher than the gain. Apart from that using a sufficiently long random id (with association to the real id in the database) makes it practically impossible to "hack" by guessing or brute forcing. – Steffen Ullrich Sep 23 at 14:42
  • 1
    "Anything can be hacked" -- correct, but that doesn't mean it's worth doing. That statement is like saying "Anything is possible if you believe in yourself!" If you have to invent quantum computing to break into an application, your application doesn't seem so valuable anymore. Anyway -- your server should be the one generating the ID, and it would be much harder to hack. It's rather bizarre that your friend is writing that off. Also, the group ID should be securely randomized and of a sufficiently large length to prevent prediction and bruteforce attacks. – Saustin Sep 23 at 14:45
  • @Jez they simply added a pin/password to public links and made the link IDs really long... Lookup "zoombombing" – schroeder Sep 23 at 15:01
  • @schroeder In our case, the password would kind of defeat the point of an "easy join" link. As for making the ID really long, yeah we could do that (I had the idea of using a GUID) but the attacker could still join the group whose actual ID had been leaked, and there would be no way to expire that invitation if it was a group ID instead of an invitation code that had been generated on the server – Ada Ducklace Sep 23 at 15:09
4

A good solution would be to make the ID very long and impossible to bruteforce, for example providing 128bits of entropy (for example about 38 digits or 22 alphanumeric characters).

Then you also need some kind of PIN or password, because otherwise the link alone would allow an attacker to join the chat, and the link could be leaked in several ways (browser history, server logs, etc.). The PIN/password should be typed by the user in a text field on the page (not in the URL). The longer the PIN or password is, the more secure your system will be. However, long PIN/passwords are a pain to enter for users. You might be able to achieve good security even with short PINs and passwords if you implement a bruteforce detection system, for example, by monitoring failed login attempts and maybe block IPs when too many failed attempts have been made.

For even better security you might want to provide different credentials to different users, so if the password was leaked you would be able to identify the user who leaked it.

| improve this answer | |
  • OP - once you implement this, you've essentially implemented a username + password system so look into password hashing and fixed time comparisons. – Prime Sep 23 at 17:06
1

In addition to the previously mentioned long random value (which might be a second parameter on the URL if you want to be obvious), I recommend two other features:

  1. Time limits. The invitation should only be valid for a few hours or days. (I used one week when I wrote one. I also gave the issuer a "resend" option, as I send the invitation as email.)

  2. Use limits. As in the invitation can be used only once. This doesn't work right for something posted in a group, but is very appropriate for something sent to a specific user. (I did this too.)

Neither of these options should show up in the URL.

One other feature I used, that might be of use: The invitation granted access rights, and could also be used to add rights to an existing user account.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.