Best Practices for "Remember Me"?
Posted: Tue May 24, 2005 12:25 pm
So I've put off implementing "Remember Me" functionality for a long time over security concerns.
I've been using an HMAC-SHA1 based authenticator for my regular session authentication: ie a cookie with the following payload: identifier+expTime+MAC(identifier+expTime). The identifier is not predictable from either username/email/password or registration order. Thus even if someone brute forced the secret key, its roughly equally hard to traget a paticular user for impersonation and unlikely to generate a random, but existing user. expTime is normally 15-30 minutes from last access.
I've played with an automatically rotating authenticator hashing key, that retains the past key to avoid expiring active sessions when the key changes.
All in all I'm pretty happy with this system.
However, now I'm thinking about how I would implement the "Remember Me" type feature. My concerns with the these features is that you can't rotate the signing key in any meaningful way without invalidating all existing tokens. In principle you can't ever rotate the key .... this is bad as you can't constrain the window of vulnerability. While outright brute-force recovery of the secret key from HMAC-SHA1 is extremely unlikely, I don't like the open ended problem.
I know a few systems that force the once a year log-in, probably for this reason.
I've been thinking about using a per-user authenticator key in the DB, so that brute forcing any paticular user doesn't allow maseradeing as another user. The per-user authenticator key can then be rotated any time the user changes thier password (an action that should invalidate all their existing tokens).
Does anyone know of any more developed "best practices" for the long-lived "remember me" authenticators -- most web discussion focuses on the shortly lived ephemeral session authenticators...
Thanks
I've been using an HMAC-SHA1 based authenticator for my regular session authentication: ie a cookie with the following payload: identifier+expTime+MAC(identifier+expTime). The identifier is not predictable from either username/email/password or registration order. Thus even if someone brute forced the secret key, its roughly equally hard to traget a paticular user for impersonation and unlikely to generate a random, but existing user. expTime is normally 15-30 minutes from last access.
I've played with an automatically rotating authenticator hashing key, that retains the past key to avoid expiring active sessions when the key changes.
All in all I'm pretty happy with this system.
However, now I'm thinking about how I would implement the "Remember Me" type feature. My concerns with the these features is that you can't rotate the signing key in any meaningful way without invalidating all existing tokens. In principle you can't ever rotate the key .... this is bad as you can't constrain the window of vulnerability. While outright brute-force recovery of the secret key from HMAC-SHA1 is extremely unlikely, I don't like the open ended problem.
I know a few systems that force the once a year log-in, probably for this reason.
I've been thinking about using a per-user authenticator key in the DB, so that brute forcing any paticular user doesn't allow maseradeing as another user. The per-user authenticator key can then be rotated any time the user changes thier password (an action that should invalidate all their existing tokens).
Does anyone know of any more developed "best practices" for the long-lived "remember me" authenticators -- most web discussion focuses on the shortly lived ephemeral session authenticators...
Thanks