Roles in encrypted cookie, security problem?

[Per Salmi]

Hi,
I was just looking over a few samples of role based security in combination
with forms based authentication. The samples I find seem to store an encrypted
list of roles in a cookie like this:

(Code snippet taken from Code Project article by Heath Stewart)

// Create a new ticket used for authentication
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(
1, // Ticket version
Username.Value, // Username associated with ticket
DateTime.Now, // Date/time issued
DateTime.Now.AddMinutes(30), // Date/time to expire
true, // "true" for a persistent user cookie
reader.GetString(0), // User-data, in this case the roles
FormsAuthentication.FormsCookiePath);// Path cookie valid for

// Encrypt the cookie using the machine key for secure transport
string hash = FormsAuthentication.Encrypt(ticket);
HttpCookie cookie = new HttpCookie(
FormsAuthentication.FormsCookieName, // Name of auth cookie
hash); // Hashed ticket

// Set the cookie's expiration time to the tickets expiration time
if (ticket.IsPersistent) cookie.Expires = ticket.Expiration;

// Add the cookie to the list for outgoing response
Response.Cookies.Add(cookie);

Is this really av safe way to store the current users available roles? I
am thinking about a scenario where a user could elevate his/hers privileges
by brute force decryption of the cookie and then create new contents for
the cookie, adding a role like "Admin" which probably could be valid in many
sites using this technique.

To me it would feel better if the list of the current users roles was not
stored on the client.
Anyone got comments on this?

Best regards,
Per Salmi

 

[Nicole Calinoiu]

If the user can decrypt the cookie, then he could just as easily modify the
user name in the cookie. Since the user name would be the key into the
user's roles collection in the case where the roles are not stored in the
cookie, there's not much difference in risk between the two scenarios.

That said, there's a much more compelling reason not to store in a cookie: a
user's role membership may change within a given usage session. When this
happens, it is usually expected that the altered roles would immediately be
reflected in the user's permissions, and that will only happen if you
refresh the role set frequently (ideally at the start of each request).
Obviously, there's a potential performance vs security trade-off here, so
there's a design decision to be made wrt the frequency of the role refresh.
When making this design decision, it's important to consider not only
"typical" usage scenarios, but examples such as the blacklisting (via
inclusion in a blacklist role or exclusion from all roles) of a user during
a session in which he is observed to be attempting potentially malicious
activities.

 

[Per Salmi]

So, what are the best alternatives to using the cookies stored UserId and
Roles list?

Where is the best place to store the FormsAuthenticationTicket?

/Per

 

[Nicole Calinoiu]

The decryption with which you are concerned is generally not a very big
worry (assuming you are actually encrypting as per the protection level
specified for the forms authentication element in your configuration file).
That said, the risk grows with increased longevity of the encryption key.
Therefore, using a manually specified key that you can change on some
regular schedule (and/or if you suspect the old key has been compromised)
might be a good idea. Requiring SSL for transmission of the authentication
cookie would be another easily configurable protective mechanism.

Another type of protection would be to require some form of additional
evidence when verifying the authentication cookie. An example of this type
of mechanism (as applied to session cookies) is shown at
http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/. It's generally
possible to spoof any additional evidence, so this technique generally only
makes it somewhat more difficult to hijack the cookie. Also, some
legitimate clients may have issues transmitting the required evidence, so
you may find it impractical to implement this technique if you serve a
varied client pool.