5

Our application has the concept of security tokens. These are cryptographically secure randomly generated strings used when generating password reset emails, as well as email confirmations for other actions. Tokens are single use and expire after a day. The tokens provide two key pieces of information. They identify a specific account, as well as prove that the person holding the token is the owner of that account.

Currently our application does not assign a specific use for each token, a token generated for resetting a password can be used to confirm another action, and vice versa.

Assuming the token is kept secure, what, if any, potential security pitfalls could this have and should our security tokens be restricted to the purpose they were originally generated for (eg. only a password reset token can reset a password etc.)

Improve this question
6
  • What could these "other actions" be? If I can use a password reset token to authorise a £1M transfer, that would be a pretty bad flaw.
    – paj28
    Nov 3, 2016 at 23:12
  • @paj28 The tokens are (for the time being) used only in email confirmations and is only usable by the one who possesses it (ideally). A token cannot be used to authorize actions on behalf of other people, only themselves. If a user wants to authorize a £1M transfer from themselves to someone else, then they are free to do so.
    – jduncanator
    Nov 3, 2016 at 23:19
  • To expand on your example. If a user initiated a £1M transfer to someone else, the system would send out an email confirmation with a security token. At this point, any security token is valid to confirm this transaction, however as the user already has a valid token (from the email confirmation for that specific transaction), it does not seem like a security vulnerability to allow a user to use a password reset token, as the user could confirm the transaction using the proper email at any point in time anyway.
    – jduncanator
    Nov 3, 2016 at 23:23
  • 1
    There are some (remote) scenarios this could go bad. A user might forward an email to someone saying "hey, I'm going out of office, approve this trivial thing for me" then that person uses it instead to reset a password, authorise a big transaction, whatever. In practice, your setup will probably be fine, but as it's pretty easy to tie tokens to actions, I'd advise you to do so.
    – paj28
    Nov 3, 2016 at 23:26
  • @paj28 You make a good point. So far I've only been thinking in one direction (using a password reset token to perform another action), rather than the other way around. As much as it is most likely not applicable to my application, it is certainly applicable to my question and is probably the correct answer.
    – jduncanator
    Nov 3, 2016 at 23:29

1 Answer 1

Reset to default
0

The sort of problem I can foresee with this is that it's vulnerable to the following sort of attack:

  1. Attacker causes your system to send a password reset email to the user. Such an email contains a valid security token plus some context, for example:
    • Telling the user what this is about;
    • Instructions for the user how to complete with the action;
    • URLs for the user to click on to complete the action.
  2. Attacker intercepts this email and adulterates it to keep the security token, but alters the context to their advantage.
  3. User receives the forged email, acts on the adulterated context, and thus unwittingly carries out some action that the attacker intended them to do.

Whether this is a realistic or fruitful attack very much depends on the details of your system. In any case, binding the tokens to the actions that they're supposed to perform removes this sort of risk.

Improve this answer
5
  • Whilst you do make a good point, I'm assuming the security token is kept secure, because as soon as an attacker can intercept password reset tokens, any security is thrown out the window. I've updated my question to reflect this. Thanks.
    – jduncanator
    Nov 3, 2016 at 23:27
  • @jduncanator: If I understand your revised question correctly, it still says that the tokens are being emailed, and email is just not secure.
    – Luis Casillas
    Nov 3, 2016 at 23:37
  • True. So essentially, tying a token to a specific action limits the potential misuse in the case that a token is compromised. However, an attacker can always intercept the token, reset the users password, and perform any action the user would be able to anyway. It doesn't necessarily have anything to do with tying tokens to actions. Whilst I agree that email is insecure, as soon as an attacker can intercept password reset emails, any security is thrown out the window (regardless of whether tokens are tied to actions or not).
    – jduncanator
    Nov 3, 2016 at 23:46
  • 1
    From reading your answer a second time, I can see that you may be alluding to the fact that an attacker could cause the user to perform an action, without them knowing they have been targeted (as opposed to the attacker changing the users password, which is going to be obvious). If that's the case, then tying tokens to a specific action is certainly going to prevent the misuse of tokens in that scenario. Your answer is definitely something I did not think about and certainly a good enough reason to tie tokens to actions. I'll accept the answer after I give time for others to comment! Thanks.
    – jduncanator
    Nov 3, 2016 at 23:50
  • @jduncanator - For password resets, you can ask the user an additional question after they click the confirm link. These tend to be pretty lame like "make of your first car?" but do at least provide some protection against an intercepted email. BTW, the more you think about passwords in detail, then more you realise they are very poor for web logins, and everyone should adopt OpenID, YubiKey, LassPass, or at least something.
    – paj28
    Nov 4, 2016 at 0:01

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.