The data stored in the token is signed to prevent tampering but not encrypted. This means it is safe to store identification information (such as user IDs) but should not be used to store confidential information (such as credit card numbers).
However, there seem to be two functions one can use on Token, sign/4 (which is mentioned in the examples), and encrypt/4 (which is not).
Are the docs wrong, or is it actually unsafe to use Token.encrypt/4 to keep data private while sending it over the wire? If so, why? Obviously, I’m not using this to send credit card numbers or some sort to the client (tbh, signing alone may even be sufficient for my usecase), but I noticed this in the docs and wanted to check
Yes, sorry, I am aware of the difference between signing and encrypting in general, but what was peculiar to me was that the docs say not to use Token for private data (as the “data stored in the token is signed to prevent tampering but not encrypted”), and yet, there seems to be an encrypt/4 function, which would imply it could be used to provide secrecy.
Really, the question is: are the docs wrong about the use of the module, or is the encrypt name misleading me?
If you look at the function docs of Phoenix.Token you’ll see that encrypt does the same thing as sign but also encrypts the payload. So by using encrypt you do not lose any features, integrity or security, you get everything that sign provides PLUS encryption – so you can also store data that you don’t want decrypted.
It seems rather pointless to encrypt on the server and decrypt on the JS side though; after all, the decrypted data will be then available in plaintext inside the browser and malicious browser addons and 3rd party JS can sniff it out, circumventing your encryption.
The more valuable scenario is to encrypt something on the JS side and send it to the server so as to thwart parties who would modify the payload in-flight (f.ex. amount of money to be withdrawn from an account, or a password).
If you look at the function docs of Phoenix.Token you’ll see that encrypt does the same thing as sign but also encrypts the payload. So by using encrypt you do not lose any features, integrity or security, you get everything that sign provides PLUS encryption – so you can also store data that you don’t want decrypted.
Yeah, I saw that, but it contradicts the moduledoc. I guess I’ll open an issue about it. Thanks for clarifying
It seems rather pointless to encrypt on the server and decrypt on the JS side though; after all, the decrypted data will be then available in plaintext inside the browser and malicious browser addons and 3rd party JS can sniff it out, circumventing your encryption.
Definitely, this wouldn’t be valuable. The short answer is: I’m passing some data to the frontend that I need to ensure authenticity of (where signing would be valuable), but I also would prefer to keep the data itself secret from a client as a means of hiding implementation details. Like I said, encryption isn’t a true necessity in my usecase, but the docs made me curious.
