Roles in encrypted cookie, security problem?

Discussion in 'ASP .Net Security' started by Per Salmi, Jan 18, 2005.

  1. Per Salmi

    Per Salmi Guest

    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
     
    Per Salmi, Jan 18, 2005
    #1
    1. Advertising

  2. 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" <> wrote in message
    news:...
    > 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, Jan 18, 2005
    #2
    1. Advertising

  3. Per Salmi

    Per Salmi Guest

    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" <> wrote in message
    > news:...
    >
    >> 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
     
    Per Salmi, Jan 19, 2005
    #3
  4. 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" <> wrote in message
    news:...
    > 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" <> wrote in message
    >> news:...
    >>
    >>> 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, Jan 20, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrew Banks

    Security roles

    Andrew Banks, Feb 16, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    321
    Mary Chipman
    Feb 17, 2004
  2. Ranginald
    Replies:
    2
    Views:
    439
    Ranginald
    Feb 6, 2007
  3. Nick Breau

    Roles Based Security and Server.Transfer Problem

    Nick Breau, Oct 1, 2003, in forum: ASP .Net Security
    Replies:
    0
    Views:
    110
    Nick Breau
    Oct 1, 2003
  4. Jéjé
    Replies:
    0
    Views:
    260
    Jéjé
    Sep 27, 2005
  5. clintonG

    The End of Encrypted Security As We Know It?

    clintonG, Mar 19, 2007, in forum: ASP .Net Security
    Replies:
    1
    Views:
    127
    Scott M.
    Mar 19, 2007
Loading...

Share This Page