Re: Roles in encrypted cookie, security problem?
From: Nicole Calinoiu (calinoiu)
Date: 01/20/05
- Next message: Joe Kaplan \(MVP - ADSI\): "Re: Access remote xml file using Credentials"
- Previous message: Ianb: "Access remote xml file using Credentials"
- In reply to: Per Salmi: "Re: Roles in encrypted cookie, security problem?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 20 Jan 2005 15:42:35 -0500
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.
"Per Salmi" <per.salmi@nospam.nospam> wrote in message
news:162409632417239777233517@news.microsoft.com...
> 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
>
>> 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" <per.salmi@nospam.nospam> wrote in message
>> news:158684632416702594956464@news.microsoft.com...
>>
>>> 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
>
>
- Next message: Joe Kaplan \(MVP - ADSI\): "Re: Access remote xml file using Credentials"
- Previous message: Ianb: "Access remote xml file using Credentials"
- In reply to: Per Salmi: "Re: Roles in encrypted cookie, security problem?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
