Phoenix.Token encryption

apoeco

Hello everyone, this is my first post here!

I am a newbie in Elixir and Phoenix (ex Ruby/Rails ) and I am having some hard time
trying to figure out how to properly set authentication in my project (Phoenix/React).

I was looking at Phoenix.Token today (as I will probably try to roll out my own authentication library/plug)
and noticed that it is using Plug.Crypto.MessageVerifier.

As MessageVerifier docs are mentioning

MessageVerifier makes it easy to generate and verify messages
which are signed to prevent tampering.

On the other hand I took a look at Plug.Crypto.MessageEncryptor .

As MessageEncryptor docs are mentioning

MessageEncryptor is a simple way to encrypt values which get stored
somewhere you don’t trust.
The encrypted key, initialization vector, cipher text, and cipher tag
are base64url encoded and returned to you.
This can be used in situations similar to the MessageVerifier, but where
you don’t want users to be able to determine the value of the payload.

So I need to ask this!

Given the fact that our js/socket clients are not trusted, why does Phoenix.Token use MessageVerifier over MessageEncryptor?
I must also note that there is a get_secret private function defined and used inside of Phoenix.Token that I really didn’t check out …

4 comments

/phoenix

1 3634 4

2017-01-04 21:25:08 UTC

Showing Posts 1 to 4

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

bobbypriambodo

Hello and welcome!

Because most of the time, signed token (as opposed to encrypted token) is enough. You usually only store safe-to-know values as the token payload, such as the user’s ID. This is also the case with JWT, the messages are signed to prevent tampering, but they’re not encrypted, so you can inspect the payload with JWT decoders available online.

Encrypted messages make sense if the payload of the message is sensitive, maybe if you store the user’s home address or any kind of private values in the payload (I don’t know why you would, though).

To sum up, authentication tokens usually are safe enough (meaning that the payload is not that private) such that using MessageVerifier will suffice. It is also secure in the sense that end users can’t tamper with the data, since the token is signed using your secret_key_base.

Do note that both tokens generated by MessageVerifier and MessageEncryptor are vulnerable to a form of session hijacking if someone can get hold of your token (even when encrypted).

Post #1

apoeco

First of all, thank you a lot for that quick response!

Well yes, that makes sense…

Maybe off topic question

That’s true. Does this hold true with JWT also? I guess so…

Post #2

bobbypriambodo

Yup! So does with the usual session key.

It all boils down to how you store the token. Are you storing it as a cookie or using localStorage? If it’s cookie, is it HttpOnly to prevent XSS? Is it Secure to prevent sending tokens via HTTP (not HTTPS)? Is your site safe from CSRF?

Post #3

apoeco

This is exactly what I imagined…
My goal is to build a phoenix project that exposes an API (for a mobile app later on) and also serves a SPA (React) .
So I was thinking that I could probably do the register/login part with plain old server-rendered html forms (using form_for) to prevent CSRF attacks and after a successful login redirect to the SPA (something like "/app") passing down a Phoenix.Token through window.userToken that only stores the user’s ID.
After that the SPA would connect to a Phoenix.Channel and interact with the API only via the channel, using the token for authorization/authentication.

Even if I don’t save the token in localStorage and save it in-memory (redux store), it may still be possible that the token might be leaked in someway from the Javascript application I think…

I wonder what is the best way to achieve the behaviour I mentioned above (SPA consuming the API via Phoenix.Channels)…