3

The typical signup procedure is of course:

  1. Alice enters email address and desired password (and possibly other data).
  2. A verification email is sent to the address Alice provided.
  3. Alice confirms her email address via a link (with a unique token) in the email.
  4. Alice now has access to the service.

But in the case of services where users invite others by entering their email addresses, does it make sense to streamline the signup procedure? If the new user arrives at the site via an email link, can't the verification email be skipped?

The flow would instead be:

  1. Alice (an existing user) invites Bob to the service by entering his email address into the service's invitation function.
  2. Bob receives the email, which has a link (again with a token) to the signup page.
  3. The signup page is pre-filled with Bob's email address, so all he has to do is pick a password (the token also gets propagated, so Bob can't craft a request to override the pre-filled email address).
  4. Bob has access immediately.

I wouldn't be surprised if some services already do this, I just haven't seen any (at least none I can recall).

As far as I can tell, the second flow provides the same amount of verification/confirmation as the first one; in either case, the user follows a link with a unique token that's tied to their address. Or, at any rate, an email account they have access to.

But is it the same? Does the altered flow provide some foothold for attackers?

2 Answers 2

2

In general it isn't necessary to require the user to re-enter their email address if the link is received via that same email address. It is important though to use SSL, expire the link as soon as a password is created, and consider expiring the link if no password has been created after a certain amount of time.

That being said, it is slightly more secure to still require the user to re-enter their email address. It's possible that an attacker could gain access to the link without the email, for example in a browser cache of a user that clicked the link from a public computer and then didn't finish setting a password. However, I would consider this scenario pretty contrived, when compared to the convenience of pre-filling the email.

1
  • I was thinking the same, pretty much. And yeah, I'm assuming most other basic precautions (SSL/TLS, token expiry, request throttling) are in place.
    – Flambino
    Commented Jul 5, 2016 at 14:39
2

I could imagine the following scenario:

  1. Bob reads the email and think "Not for me, but this site would be perfect for my good friend Mallory". Bob forwards the email to him.
  2. Mallory now has the ability to sign up with Bobs email.
  3. Mallory uses the ability to impersonate Bob to e.g. stage social engineering attacks, or just to smear Bobs reputation.

Depending on how you formulate the email, the risk of this happening could be quite small. But no matter how clear you are point #3 is bound to happend some times, because even if you are clear people don't really read what you write in emails.

It should also be noted that Bob would have the ability to stop Mallory by doing a password reset (the password would be sent to Bobs email). But by then Mallory could allready have caused some damage.

1
  • 1
    Good point. The service in question would be for work and collaboration, though, so Alice's invitation to Bob wouldn't be a generic mass email, but one intended specifically for Bob from Alice, and it'd be sent in a professional context. Lower risk of Bob just forwarding it, but potentially bigger problems if he does...
    – Flambino
    Commented Jul 13, 2016 at 8:56

You must log in to answer this question.

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