1

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?

Improve this question
3
  • Looks like security.stackexchange.com/questions/43705/… and security.stackexchange.com/questions/109616/… could be relevant here.
    – Markus
    Commented May 9, 2019 at 9:20
  • Hello Markus and welcome to Information Security. When you say that you researched a topic but couldn't find anything, please clarify what you found. Partial results with a statement why they are not applicable to your specific case can still be very useful. Otherwise, great question!
    – user163495
    Commented May 9, 2019 at 12:51
  • 1
    @MechMK thanks for pointing this out, good point. I’ll try to remember that.
    – Markus
    Commented May 9, 2019 at 15:36

2 Answers 2

Reset to default
2

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.

Improve this answer
4
  • 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
    Commented May 9, 2019 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
    Commented May 9, 2019 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
    Commented May 9, 2019 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
    Commented May 9, 2019 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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .