6

I have an application that will send an SMS reminder for user containing a URL to log on. I would like to avoid user typing in username/password and log him in directly. For that I plan to use an access token and add it to the url, e.g:

www.mydomain.com?token=JFPIENBFIOHGDFGP3423432

Now since that is an SMS, I cannot hide it behind the "a" tag. So I would like to limit the length of the token as much as possible not to scare users too much. Perhaps also limit the symbols to only capital letters or something or some other way of "beautifying" it.

Is this is a proper approach to do it and if yes, then what security should be applied to the token. As far as I can see I need this:

  1. Generate the token using CSPRNG
  2. Make sure it's enough entropy (my application does not deal with very sensitive info, so I suppose say 32 bits should be enough, maybe even less as the username/password is just phone/digital pin code)
  3. Make sure that the token is one-time and/or short lived (e.g 24 hours)
Improve this question
2
  • Since you're sending it via SMS, you'd strengthen this quite a bit if the token were valid for only one login. Allowing the token to be used for a limited time period, say 24 hours, might also help. If you allow reuse of the URL, consider limiting the subsequent logins to the same browser that made the original request, validated with cookies distributed during the first login.
    – John Deters
    Commented Apr 15, 2016 at 13:46
  • Yes, thank you. We plan to make it limited to either on time or one day, I'll add it to the question.
    – Ilya Chernomordik
    Commented Apr 15, 2016 at 13:59

1 Answer 1

Reset to default
6

That's certainly a reasonable approach. I would, as you suggest in your post, limit it both to a token that is both time-bound and one-time-use.

How long it needs to be depends on how much entropy you feel you need to introduce. If you were to beautify it by just using uppercase characters and numbers, that given you a character space of 36 characters. An 8 character token, chosen completely randomly from this space will have ~41.36 bits of entropy. This is not enough for a password, but could be potentially usable as a token. Depending on how many are issued, and how many attempts to validate them your application supports, this might not give you enough margin for safety, however. A 12 character, completely randomly generated token would offer you around 62 bits of entropy, and if you wanted to go to 16 characters, you would be getting into password-quality strength, with over 82 bits of entropy.

So, it's definitely a workable scheme with good randomness, and the length of the tokens depends primarily on how much safety margin you want. 8 characters is marginally workable, 12 characters is probably a pretty reasonable sweet spot, 16 if you value security more than compactness.

Improve this answer
5
  • Thank you for the answer. Are there any good schemes to transform random byte output from SPRNG to the chosen character space? (P.S. I use .NET)
    – Ilya Chernomordik
    Commented Apr 15, 2016 at 14:50
  • I would also ensure that this endpoint is rate limited to avoid someone brute forcing valid tokens. news.softpedia.com/news/…
    – Casey
    Commented Apr 15, 2016 at 14:58
  • @Casey I considered that, and with a space this size (and tokens that are one time use and time limited) brute force attacks are probably not going to be a security threat, but even so, rate limiting is a good idea, if for no other reason that to prevent an attacker from DoSing your application.
    – Xander
    Commented Apr 15, 2016 at 15:04
  • @IlyaChernomordik Yes, I've done it before. Let me see if I can find a published example.
    – Xander
    Commented Apr 15, 2016 at 15:06
  • @IlyaChernomordik Found one! stackoverflow.com/a/19068116/321790 Remove the lowercase letters from that example, and you have exactly what I described.
    – Xander
    Commented Apr 15, 2016 at 15:07

You must log in to answer this question.

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