On Tuesday, June 20, 2017 at 1:01:05 PM UTC-4, Mike Orr wrote:
>
> That says that storing the user ID in a cookie is a bad idea, but
> isn't that what AuthTktAuthenticationFactory does?
>
Storing a user_id AS the cookie payload for auth is a bad idea. Storing a
user_id IN a signed (or encrypted) payload however is usually fine.
A common TERRIBLE authentication policy is to have plaintext
username/userid data as a cookie. That can easily be spoofed, stolen, etc.
I'll try to explain what many others have already said slightly
differently...
One common improvement to insecure session concept is to use a signed
cookie payload. The cookie may have the user_id in it, but the payload
would be in a structure like this:
payload['timestamp'] = time.time()
serialized_payload = serialize(payload)
signature = sign_payload(serialized_payload, site_secret))
cookie_value = ':'.join([serialized_payload, signature])
A timestamp is added to the payload to limit how long it is effective for,
it's then serialized and signed.
The server can reject any cookies for being before a certain timestamp, or
signed with the wrong secret.
An attacker knowing the user_id is irrelevant, because they can't craft a
payload signature.
The weakness is that the cookie itself could be intercepted and stolen.
AuthTkt is another common improvement to Sessions and can either work
alongside an encrypted/signed session OR in place of it.
In the original Apache mod_perl implementation (which became mod_auth_tkt
in c, IIRC), an authtkt was basically a signed cookie that simply
authenticated a username+ip combo as "valid" for a fixed time. It was
pretty lightweight and done (in part) to offload database session checking
-- which was heavy then. It had routines to be tracked/checked server-side
though, so a developer could revoke a specific ticket (instead of cycling
out a shared secret - which would revoke them all).
Modern AuthTkt implementations -- like Bert's -- have a lot of hooks for
more granular permissions and server-side checking, as this stuff is all
incredibly simple and rather lightweight now.
One of the neater things with AuthTkts is that it becomes a bit easier to
have "global" server side sessions for a user. i.e. you can have a single
user with multiple devices/auth-tkts, and each ticket authorizes to a
shared session on the server (e.g via the user id).
--
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 post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/66a9cbbb-de5f-4b84-b765-0a47c8acaff2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
