1

In my question and answer application, Joe signs up, logs in and adds a question. He then shares the question via email to his trusted friends.

How safe is it to provide a link within that app generated email to allow his friends to directly respond to the question without having to register on the site?

The key goal is that I would like the user's friends to be able to respond to his question without having to register on the application site. Assume that the link embeds the email id of the receiver, so the app can map each response to the email id that initiated that link.

What precautions do I need to include to avoid or detect malicious clicks on that link?

  • Not super user friendly, but adding a ReCaptcha to the comment box could be of some helpt to the final solution – Lighty Oct 9 '14 at 14:15
  • I don't think you'd need to worry about very many people clicking on a link from an unsolicited email anyways. – Andrew Hoffman Oct 9 '14 at 18:31
1

Create a cryptographic random number and add it as a parameter in the url (token). Then only show the real page if it's a valid token. Tokens should be store in the database obviously.

How safe is it to provide a link within that app generated email to allow his friends to directly respond to the question without having to register on the site?

It is very safe if your cryptographic random number is very long. Session/Authentication also simply use a cryptographic random number. If you consider your session/authentication cookie secure, then you can also consider that one secure.

Guessing a very long cryptographic random number will take a LOT of time. For more security, you can consider

  • one time token
  • token that expire with time

What precautions do I need to include to avoid or detect malicious clicks on that link?

None. You cannot differentiate between an attacker and the real user. But this is true for everything on the web... An attacker can try to guess the password of a user the same way he can try to guess your token. But, both will probably take a very long time hence it is not practical.

  • I would add that, the link shouldn't be valid for more than a day, should only be valid for one use. – Paraplastic2 Oct 22 '14 at 19:54
  • @Paraplastic2 Already mentioned in my post : "one time token" and "token that expire with time" – Gudradain Oct 22 '14 at 20:14
  • I must be blind that I missed "one time token", sorry. I personally prefer to define details. e.g. time = 24 hours. Having worked with developers that thought 6 months was acceptable, I feel like I have to explicitly state everything. – Paraplastic2 Oct 22 '14 at 21:35
2

I would create tokens (Some random hashes or GUID) for each intended user and pass that in the query string to identify the individual users. Kind of like a temporary password. Putting this on the query string is convenient for the user. Making the GUID, or token temporary or for one time use will reduce sharing. Your only concern after this is if your users need to edit or amend their response to your question after the fact. I would send the question ID along with the GUID. As an example:

http://example.com/thread/27?AHG324y6CVSA452aw34aF

Where http://example.com is your domain, thread is your controller/action (MVC) and 27 identifies the thread, or question being asked. You can then use their token AHG324y6CVSA452aw34aF to identify who submitted the answer. (Unless your going for anonymity then that is up to you, but users wont trust you, or rather, I wouldn't trust you, with this approach).

Sounds like a fun project.


EDIT:

Important note: GUIDs are unique, not random so they should not be used in this scenario.

  • Thanks, are you suggesting this token as an alternative to sending email id within the query string? Or does it make that click more trustworthy inherently? – Anand Oct 9 '14 at 14:10
  • It would work until someone posts that link to reddit and hordes of trolls takes over. – ThoriumBR Oct 9 '14 at 14:17
  • 1
    @ThoriumBR - the idea is that the token should be of limited usefulness. It shouldn't allow unlimited posting. – AJ Henderson Oct 9 '14 at 14:21
  • don't use random hashes or GUID, it is not secure. Use cryptographic random number. The 2 are not the same. – Gudradain Oct 9 '14 at 14:47
  • 1
1

Including a unique identifier or token in each individual e-mail is the best bet. This token should be random, hard to guess, and from a large enough set that randomly entering values will never produce a valid token.

These tokens should then be limited in the scope and scale of what they can do. If you limit the users to a single response and commentary on that response, then sharing the link will be largely mitigated as only one main entry can be made from that e-mail without registering.

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.