2

We were told to send an email with a link to the users. The users will get a token in the URL where they will be able to chose some options and post their selection. Example URL: https://example.com/DoSomething?token=wer545w5e54r

The application is being made in MVC .Net, Web API and is hosted in a server with https.

Currently, we are validating if the token exists we accept the transaction otherwise we are returning 401 error.

Could you tell me what are the security points that we consider on in order to make secure our application?

Our client does not want to deal with a sign-in form

Improve this question
2
  • 2
    For the limited context you describe, what you're doing seems to be a good practice. Perhaps you're asking "is it enough?" Or is your question broader (if so it seems overly broad). To answer "in order to make secure our application", security peeps need some idea of what assets you're protecting and from what threats.
    – Sas3
    Aug 20, 2017 at 2:01
  • As a heads up, those security tokens are getting logged by IIS be default. If an attacker were ever to gain access to your IIS logs, they could impersonate any of the sessions which are still valid. You may want to consider passing those tokens along as a custom header..
    – Dan Landberg
    Sep 18, 2017 at 19:00

1 Answer 1

Reset to default
1

When using a One-Time-Token like that, you usually have at least four problems:

  1. Time frame of validity. If the token is valid for too long, it might get compromised, if too short, the method of delivery might be too slow to allow for a good user experience.
  2. Method of delivery. You do not want to send those tokens over an insecure channel like mail without PGP or S/MIME. If you do, the token (effectively the username and password during said timeframe from 1) might get compromised and everything breaks horribly. If you use PGP or S/MIME, that puts a heavy Burden on the users, effectively restricting the user base to about 1% of what is possible, as a rough estimate, as others do use neither technology and do not know how (and you're effectively putting the "hassle hurdle" to register quite high)
  3. Method of requesting such a One time token. If you allow for any unauthenticated user to put in a name and have you use some (probably computationally hard and resourceful) crypto and a communication channel, there's a higher attack surface for DDoS-Attacks.
  4. Usability. If this does not yet sound like UX hell: what about people that do not have PGP on their phones (not free on most platforms) but want to use your service while on the go? What about people using a machine at some other place, like internet Cafés? You do not want to also check mail or whatever way to send the token you come up with there.

Oh and while I'm at at: your question sounds like you're never invalidating the tokens. That's horrible for many reasons, as is the length of your example token - it should have a lot more entropy and a lot more characters.

Improve this answer
4
  • 1
    seems https + web-based email mitigates #2 and #4...
    – dandavis
    Aug 20, 2017 at 10:52
  • 1
    @dandavis only if the web based mail is on the same machine. In which case you shift the authentication problem into another domain instead of solving it. As long as the email travels through the Internet unencrypted, you're out of luck, regarding real security
    – Tobi Nary
    Aug 20, 2017 at 12:26
  • Hmm, I thought we were talking about "internet Cafés" and the like? How many hackers can intercept backend-to-backend traffic?
    – dandavis
    Aug 20, 2017 at 20:01
  • You should also address how those tokens are being generated. If the tokens are being generated in a predictable fashion, an attacker could easily guess what a valid auth token might be.
    – Dan Landberg
    Sep 18, 2017 at 19:02

You must log in to answer this question.

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