Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add extra information in token #56

Closed
morenoh149 opened this issue Sep 24, 2020 · 4 comments
Closed

Add extra information in token #56

morenoh149 opened this issue Sep 24, 2020 · 4 comments

Comments

@morenoh149
Copy link

morenoh149 commented Sep 24, 2020

Thanks for the package!

I'm trying to more securely create magic links. Say we want to send emails where users can approve a purchase. Right now we can generate a token

User = get_user_model()
user = User.objects.first()
magic_link = f"{HOSTNAME}/transaction/49/approve{get_query_string(user)}"

But if a motivated attacker wanted, they could submit another pending transaction, 59. And

GET HOSTNAME/transaction/59/approve?sesame=1234

If we could add the transaction id in the token, the api could unpack and apply the operation.

dict = get_parameters(user)
dict['transaction'] = 59
token = get_token(dict)
magic_link = f"{HOSTNAME}/transaction/approve?token={token}"

Is this already supported?

@aaugustin
Copy link
Owner

aaugustin commented Sep 28, 2020

No, this isn't currently supported.


Adding this feature would require:

  • adding an optional parameter to create_token, parse_token, and other functions that call them;
  • inserting its content in the output of get_revocation_key.

This raises the question of serializing to bytes in a cryptographically secure way arbitrary Python objects. AFAIK __hash__ isn't cryptographically secure. Alternatively make the optional parameter a string or bytes only.


Generally speaking:

  • if an attacker gets hold of a token you're in a bad place so I'm not sure I want to encourage this pattern;
  • a GET request shouldn't have side effects; it should display a button that the recipient can click to approve the transaction, perhaps after checking some info.

So I'm not sure I want to move forwards with this.

@morenoh149
Copy link
Author

morenoh149 commented Sep 28, 2020

@aaugustin
Copy link
Owner

I see. I'm not sure I'm willing to develop as much attack surface as JWT ;-)

@aaugustin
Copy link
Owner

I think #60 will help you do what you want. Make one scope per transaction e.g. scope = f"transaction-{transaction}" and you should be good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants