Are tokens encrypted with `Token.encrypt/4` not safe to use for private information?

ollien

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).

Looking at the source code for encrypt/4, it seems that this actually uses Plug.Crypto.encrypt/4, which does seem to actually perform crypto with chacha20 (plug_crypto/lib/plug/crypto/message_encryptor.ex at v2.0.0 · elixir-plug/plug_crypto · GitHub - one layer deeper, but this is called directly).

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

4 comments

/phoenix #token

0 465 4

2024-03-20 12:30:07 UTC

Showing Posts 1 to 4

Show Best Posts
Show All Posts (oldest first)
Show All Posts (newest first)

realcorvus

Signing and encrypting are different operations. Token.encrypt is good for keeping data private. Token.sign is not meant to keep data private, rather its so you can verify the integrity of the message sent over the wire. https://stackoverflow.com/questions/454048/what-is-the-difference-between-encrypting-and-signing-in-asymmetric-encryption

Post #1

ollien

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?

Post #2

dimitarvp

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).

Post #3

ollien

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.

Post #4

— All posts loaded —