2

I've searched this site and the web for an answer to this question, but haven't found what I'm looking for, so here goes. Pointers to existing relevant answers are much welcome as well.

I'm building a web app where users can be in private groups. In order to join these groups, existing members can send to-be members a link to the group with a token in it. I'm wondering what precautions I should take regarding this token, so random people can't guess it and join a group. I'm currently generating a 256 bit random number (from a cryptographically secure random number generator) associated with the group that is then serialized to a string and sent as part of the URL (using HTTPS of course).

My question is, would I gain anything by hashing this token using e.g. bcrypt, and comparing the hash server-side in the group join operation? Would the answer to this change if I add a time-based component, so invitations are only valid for a certain time interval?

1

I've decided to not use bcrypt, since it looks like it is designed for weak passwords that need salting, which a cryptographically random 256 bit number definitely isn't. The current approach is:

  1. Create a token based on a SHA256 sum of the 256 bit secret plus a serialization of the expiry date.
  2. Send this token to the user that wants to invite others, as part of a link.
  3. The receiving user that wants to join a group clicks the link, and the server validates that, given the SHA sum and the expiry date, the token is not expired and the sums match when doing the same calculation again.
  4. 🥳

Any comments on the validity of this approach are greatly appreciated.

  • 1
    The security of this resting only on the fact that it's impossible to guess in a limited period of time. There are some interesting side effects here. First, anyone with it can forward it. Second, these will show up in history, mail, and server logs, so anyone with that access can grab them and use them. – Steve May 9 at 15:13
  • These are valid points. The forwarding is intentional, everyone in the group is equal and may invite others at their discretion. Regarding logs etc., does this differ from time-limited invite links from e.g. Slack? I’m figuring that if a user’s email or history is compromised, there’s little I can do anyway. Thoughts? – Markus Wüstenberg May 9 at 15:38
  • Not familiar with how Slack builds their links. Logs and history are difficult because there's a good chance they're already in a position of power, but at the same time they might not be because someone made a copy and shoved them onto a share somewhere. – Steve May 9 at 16:12
  • You could have a max-uses counter server-side for each token, incremented every time someone uses the token. This way if people send the token to a high traffic site full of mischievous users, they won't add thousands of users on the channel. – ThoriumBR May 9 at 16:13
0

You give very little detail on the amount of security you need, but I think you are overdoing it.

I'd do a smaller token, maybe 64 bits, with good randomness and then just limit the repetition rate with which clients can present you said links.

Assuming you create some thousands links per group (say, for example, 50.000) and that you limit the tests to 1 per second an attacker will need, on average, 5 million years to find a link.

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.