10

We have a system in which external users can be invited to our identity management system. The users are not employees of our company, but of our customers. The administrators of the customer do not have access to the system the users are invited to.

Currently we send invite emails to the users email addresses that contain links that are valid for 7 days. The problem is that not all users can or want to respond to that mail within the 7 days - for example because they are on holiday.

This leads to manual "re-issuing" invite mails to users which is a lot of work. It is done by our employees, because the customer administrators do not have access to the system - as mentioned above. We'd like to minimize this manual intervention but we're not sure if the measures we proposed are a good idea from a security perspective. I specifically ask about user invites, because in this case the user does not initiate the invite themselves, and have no control over when the invite happens. Can you please help us out?

  • Should user invite links expire at all - if so, what would be a good expire time?
  • Would it be a good idea to let users "extend" their invite if they click on it after it has already expired - for example by sending another email with a new invite link?
Philipp Grathwohl
  • 203
  • 1
  • 6

2 Answers2

9

Should user invite links expire at all - if so, what would be a good expire time?

That is a question that doesn't have a general answer: it depends on the value of the resource you're protecting, who are the people receiving your invitations, how secure is the channel you use to transmit these invitations and what are the threats you're trying to protect against.

However, generally speaking, never-expiring invitations aren't a very desirable property: in most cases, it doesn't make much sense for someone to accept an invitation 10 years after it's been issued but it does open a (slight) security risk in the sense that very old, but still active, invitations will grow the size of the valid key space in relation of the total key space. In other words: an attacker trying out every potential key has more chance of finding a valid one.

Would it be a good idea to let users "extend" their invite

I can't think of any scenario in which this would be a desirable functionality: it's effectively the same thing as having unlimited lifetime for the invitation except that it's more complex for everyone (developer as well as user).

Stephane
  • 18,557
  • 3
  • 61
  • 70
  • 1
    A good rule-of-thumb in my opinion is one month of validity. In some business settings, preparations for projects can be sent well in advance, and sometimes people will only bother with invites to something when they actually need it. –  Apr 02 '20 at 09:46
  • I pretty much have the same default (one month) as a starting point, when I don't know enough about the final threat and usage model. I should have mentioned it, so, thank you @MechMK1 :) – Stephane Apr 02 '20 at 09:50
  • Quite the opposite. I would limit the invite to the end of the next business day. If they are on holiday, they miss it anyway. If they only follow invites at the last possible moment, they'll learn. You may do something so that clicking on expired links informs the admin and makes it very quick and easy for them to send a new invite. – gnasher729 Apr 02 '20 at 11:50
  • @gnasher729 I think that might come out to the same as allowing the user to extend the invitation for himself, because the "Admin" in this case might be some sales person who might or might not validate if the failed invite is legit or not ... My guess is that they would not and thus wouldn't add a security value, would it? Instead it would add even more manual work. – Philipp Grathwohl Apr 02 '20 at 12:59
4

Consider counting only business days

If you're worried about vacations and holidays, consider excluding weekends and holidays from your counting. This might be difficult if your users are spread across different nations, but I think there's value in counting business days rather than standard days.

Ten business days is three weeks, which should be pretty good for avoiding holidays (unless you're talking about those larger European holidays). Don't try to spell out this policy and how you count days in the email, just say when it'll expire. For users who will send the invitations, say the system supports 12+ days (since you're guaranteed at least non-business days).

Still, as Stephane noted, there is no standard answer for how much time is appropriate. It depends on your users. If counting business days is too cumbersome, just pick a larger number.

Weigh the pros and cons of extending the expiration time.

  • Is there a security risk you're trying to limit?
  • Is it unfair to other users to wait too long?

I strongly suggest against extremely long periods. 20 business days or else 30 calendar days sounds good to me as an upper bound. Anybody on vacation for that long isn't really going to complain about just barely missing the token's window (they'll just ask for a new token).

"Extending" an invitation is nonsensical to me.

  • An informal inquiry for a new invitation should be sufficient
  • Don't advertise that it's possible if you're worried about abuse
Adam Katz
  • 9,718
  • 2
  • 22
  • 44