ObSSOCookie

One of my collegues asked this question that is cookies really secure even if people call it secure cookie??

That gave me some time to think and research... Thought sharing this will help someone...
==============================================================

I am assuming you are asking for 10g since you have asked for obSSOCookie. 11g uses OAMAuthnCookie in the following format: OAMAuthnCookie__

Secure Cookie is what we use…

Normally for a secure cookie to be hacked, you need to have IP Spoofing at a system level and then cookie replay attack. MD5 sum will go for a toss if anyone tampers on the way. It can be even update of timezone in your machine. But remember cookie itself is a compromise between security and convenience. The solution for this to change the cookie everytime. 11g Cookie uses this technique and is issued per webgate and it rotates the entire cookie contents on every request. Cookie itself changes

Excerpts from doc:

http://docs.oracle.com/cd/E12530_01/oam.1014/b32420/v2sso.htm#BJFDEIDF

7.3 Single Sign-On Cookies

The Access System implements single-domain and multi-domain single sign-on through an encrypted cookie called the ObSSOCookie. The WebGate sends the ObSSOCookie to the user's browser upon successful authentication. This cookie can then act as an authentication mechanism for other protected resources that require the same or a lower level of authentication.

When the user requests access to a browser or another resource, the request flows to the Access Server. The user is logged in, and the ObSSOCookie is set. The Access Server generates a session token with a URL that contains the ObSSOCookie. Single sign-on works when the cookie is used for subsequent authorizations in lieu of prompting the user to supply authorization credentials.

When the cookie is generated, part of the cookie is used as an encrypted session token. The encrypted session token contains the following information:

·         The distinguished name (DN) of the authenticated user.

·         The level of the authentication scheme that authenticated the user.

See "About Authentication and Authentication Schemes" for details.

·         The IP address of the client to which the cookie was issued.

·         The time the cookie was originally issued.

·         The time the cookie was last updated.

If the user has not been idle, the cookie is updated at a fixed interval to prevent the session from timing out. The update interval is one-fourth of the length of the idle session timeout parameter. See "Viewing AccessGates" for details.

Unencrypted ObSSOCookie data includes:

·         Cookie expiry time.

·         The domain in which the cookie is valid.

·         An optional flag that determines if the cookie can only be sent using SSL.

7.3.1 Security of the ObSSOCookie

The ObSSOCookie is a secure mechanism for user authentication. When the Access System generates the cookie, an MD-5 hash is taken of the session token. When the ObSSOCookie is used to authenticate a user, the MD-5 hash is compared with the original cookie contents to be sure no one has tampered with the cookie. MD-5 is a one-way hash, so it cannot be unencrypted. The Access Server does the comparison by hashing the session token again and comparing the output with the hash of the token already present in the cookie. If the two hashes do not match, the cookie is corrupt. The system relies on the fact that if someone tampers with the session token, the hashes will not match.

The single sign-on cookie does not contain user credentials such as user name and password.