Passing `signed: true` in options breaks session decoding. about fastify-secure-session HOT 8 CLOSED

https://github.com/fastify/fastify-cookie/blob/master/package.json#L51 depends on cookie-signature, which introduce this problem. I think it would be better to solve this problem there.

from fastify-secure-session.

I think so, yes. A lot of time has passed, my memory is a bit blurry on this detail.

from fastify-secure-session.

I think this should be properly fixed - or maybe we should throw.

As far as I understand the code, this should work - there might be something odd at play - maybe some incompatibilities between cookie-signature and this module.

from fastify-secure-session.

@mcollina

Just to make it clear what fastify-cookie does in case of signed=true:

E.g. if we have cookie foo=bar it adds signature foo=bar.<signature>.

In case of fastify-secure-session it splits cookie https://github.com/fastify/fastify-secure-session/blob/master/index.js#L77 by ;. First part is cypher text, rest - is considered as nonce. But if we add signed=true in "rest" part we receive not only nonce, but signature as well:
foo=<cypher_text>;<nonce>.<signature>
So this module considers that nonce part is <nonce>.<signature> and checks it length that should be 24. But obviously it would be longer because of .<signature>.

So maybe it just worth to check if there's a dot symbol in nonce part and either ignore the signature. Or maybe first - validate signature, then split to cypher and nonce ignoring symbols after .

from fastify-secure-session.

What I do not understand is why the .signature part is still there. We are getting it from fastify-cookie and cookie-signature.. and the signature part should have already be extracted.

(FYI, using cookie-signature with this module does not add any security benefits).

from fastify-secure-session.

Just found this issue after researching why the session doesn't work. signed: false makes it work.

FYI express cookie stores the signature in a different cookie with same options, named cookie.name.sig. Maybe this is more clear and avoids bugs like above.

from fastify-secure-session.

What I do not understand is why the .signature part is still there. We are getting it from fastify-cookie and cookie-signature.. and the signature part should have already be extracted.

(FYI, using cookie-signature with this module does not add any security benefits).

https://github.com/fastify/fastify-cookie/blob/master/package.json#L51 depends on cookie-signature, which introduce this problem. I think it would be better to solve this problem there.

Just to understand what you think the solution to the problem is (roughly):

The cookie should not contain the .<signature> suffix added by fastify-cookie when signing is enabled at that point?

from fastify-secure-session.

I was not able to reproduce the error reported in this issue. Despite being passed signed: true, the cookie is decoded correctly by the library.

@SkeLLLa could you please create a public repo where the error is reproduced (if it can still be reproduced) so that I can have it as an up-to-date reference to the problem?

Thank you.

from fastify-secure-session.