First off, the refresh/access tokens are sensitive credentials that must be protected from exposure to third parties.
I would personally consider this implementation as a low security risk when it comes to the two tokens, as they'd be left as plaintext in the browser's settings/profile whether the connection was on http or HTTPS. This would be completely insecure and a high security risk if the connection/server was http, as the data would be transferred in plaintext and is fully susceptible to MITM attacks or network packet sniffing. To be clear, IMHO: storing this stuff in a cookie is not an issue. Storing this stuff in an **unencrypted** cookie without TLS is an issue. For this type of data, at a minimum, calls to request.response.set_cookie should contain `httponly=True` and `secure=True`; the app should also be under https only. If I understand how your system uses these credentials correctly, `samesite=strict` should also be added. There are two concepts when it comes to Cookie Data. * signing * encryption Signing the cookie just creates a digest of the payload with a site secret. It is used to prove the data originated from the site. Encrypting the cookie makes it unreadable without the key. Pyramid's sessions, by default, are the following: (https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/sessions.html) * unencrypted, but signed/authenticated * fully contained in the cookie (Client-Side Sessions) IMHO, putting this data in a standard Pyramid client-side session wouldn't fix the security concerns either - even though the information is signed, which authenticates it originated from your app, it could be extracted from the user's browser and would be susceptible to mitm attacks if the connection were not https. There are also the concerns with the cookie not being locked down with the kwargs mentioned above. If I were to be stashing this information, I would consider the following two options: 1- Store in an Encrypted cookie. I am not sure if there are any open source projects on PyPi that automate this within Pyramid, but there are many that will handle the generic encryption/decryption. Alternatively, you can use middleware to encrypt/decrypt the cookie data. 2- Store in a Server-Side session. There are many projects in the pyramid ecosystem for this. If this method is used, you need to ensure the cookies used for authentication/authorization/login-status are either encrypted or are HTTPS only. If they are not, you should require re-authentication for the user to access this information. On Tuesday, November 28, 2023 at 2:12:33 PM UTC-5 Scott Lawton wrote: > Some followup: > - > https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/sessions.html > has a big section in red: 'By default the SignedCookieSessionFactory() > <https://docs.pylonsproject.org/projects/pyramid/en/latest/api/session.html#pyramid.session.SignedCookieSessionFactory> > implementation > contains the following security concerns: > > ... which seems to argue against session, but maybe doesn't apply to > access/refresh tokens? And/or maybe setting the cookie like we do isn't any > better? > > We also tried to follow > https://docs.pylonsproject.org/projects/pyramid/en/latest/whatsnew-2.0.html#upgrading-auth-20 > > ... but not sure we did so correctly. That's what we're looking for > feedback! > > Scott > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/93a2b140-d1ab-430d-9e48-a8975c4f2b5an%40googlegroups.com.
