Index: openacs-4/packages/acs-core-docs/www/security-design.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/security-design.html,v diff -u -r1.8 -r1.9 --- openacs-4/packages/acs-core-docs/www/security-design.html 30 Nov 2002 17:16:24 -0000 1.8 +++ openacs-4/packages/acs-core-docs/www/security-design.html 28 Feb 2003 05:36:05 -0000 1.9 @@ -1,5 +1,5 @@ -
+
by Richard Li, Archit Shah
OpenACS docs are written by the named authors, but may be edited
@@ -43,10 +43,10 @@
for a secure authentication token. However, the basic architecture here lays
the foundation for a secure system and can be easily adapted to a more secure
authentication system by forcing all logins to occur over HTTPS.
The authentication system issues up to four signed cookies (see below), -with each cookie serving a different purpose. These cookies are:
name value max-age secure? ad_session_id session_id,user_id SessionTimeout no ad_user_login user_id Infinity no ad_user_login_secure user_id,random Infinity yes ad_secure_token session_id,user_id,random SessionLifetime yes
ad_session_id
reissued on any hit separated by more than SessionRenew seconds from the -previous hit that received a cookie
is valid only for SessionTimeout seconds
is the canonical source for the session ID in ad_conn
ad_user_login
is used for permanent logins
ad_user_login_secure
is used for permanent secure logins
contains random garbage (ns_time) to prevent attack against the secure +with each cookie serving a different purpose. These cookies are:
name value max-age secure? ad_session_id session_id,user_id SessionTimeout no ad_user_login user_id Infinity no ad_user_login_secure user_id,random Infinity yes ad_secure_token session_id,user_id,random SessionLifetime yes
ad_session_id
reissued on any hit separated by more than SessionRenew seconds from the +previous hit that received a cookie
is valid only for SessionTimeout seconds
is the canonical source for the session ID in ad_conn
ad_user_login
is used for permanent logins
ad_user_login_secure
is used for permanent secure logins
contains random garbage (ns_time) to prevent attack against the secure hash
ad_secure_token -
is a session-level cookie from the browser's standpoint
its signature expires in SessionLifetime seconds
contains random garbage (ns_time) to prevent attack against the secure +
is a session-level cookie from the browser's standpoint
its signature expires in SessionLifetime seconds
contains random garbage (ns_time) to prevent attack against the secure hash
user_id is extraneous
The Tcl function (sec_handler) is called by the request processor to authenticate the user. It first checks the ad_session_id cookie. If there is no valid session in progress, @@ -86,7 +86,7 @@ immediately
nothing: if the cookie is present, it remains
The current state of the permanent login cookies is not taken into account when determining the appropriate action. -
previous login state permanent login requested secure connection action on insecure action on secure other y y set set same y y set set other y n set delete same y n set nothing same n y nothing delete other n y delete delete other n n delete delete same n n delete delete
ad_user_login +
previous login state permanent login requested secure connection action on insecure action on secure other y y set set same y y set set other y n set delete same y n set nothing same n y nothing delete other n y delete delete other n n delete delete same n n delete delete
ad_user_login callssec_setup_session which actually calls sec_generate_session_id_cookie to generate the new cookie with refer to the appropriate user_id. If the connection is secure @@ -206,13 +206,13 @@ token_id is returned out of the entire set of cached token_ids. In addition, a thread-persistent cache called tcl_secret_tokens is maintained on a per-thread basis.
Thus, the L2 ns_cache functions as a server-wide LRU cache that has a -minimum of 100 tokens in it. The cache has a dual purpose:
LRU cache Note that cache misses will only occur in the +minimum of 100 tokens in it. The cache has a dual purpose:
LRU cache Note that cache misses will only occur in the multiple server case, where a user agent may have a signature guaranteed by a -secret token issued by another server in the cluster.
signature cache Since the cache always maintains a +secret token issued by another server in the cluster.
signature cache Since the cache always maintains a minimum of 100 (set by a parameter) tokens populated at startup, it can be used to provide a random token for signature purposes.
The per-thread cache functions as an L1 cache that indiscriminately caches -all secret tokens. Note that this is not an LRU cache +all secret tokens. Note that this is not an LRU cache because there is no cache eviction policy per se -- the cache is cleared when the thread is destroyed by AOLserver.
-ad_user_login user_id Logs the user in as user +ad_user_login user_id Logs the user in as user user_id. Optional forever flag determines whether or not permanent cookies are issued. -
ad_user_logout Logs the user out.
ad_check_password user_id password -returns 0 or 1.
ad_change_password user_id new -password
-ad_sign value Returns the digital signature of this +
ad_user_logout Logs the user out.
ad_check_password user_id password +returns 0 or 1.
ad_change_password user_id new +password
+ad_sign value Returns the digital signature of this value. Optional parameters allow for the specification of the secret used, the token_id used and the max_age for the signature. -ad_verify_signature value signatureReturns +ad_verify_signature value signatureReturns 1 or 0 indicating whether or not the signature matches the value specified. The secret parameter allows for specification of a different secret token to be used.
-ad_set_signed_cookie name data Sets a -signed cookie name with value data.
ad_get_signed_cookie name Gets the signed cookie +ad_set_signed_cookie name data Sets a +signed cookie name with value data.
ad_get_signed_cookie name Gets the signed cookie name. It raises an error if the cookie has been tampered with, or if -its expiration time has passed.
ad_set_client_property module name -data Sets a session property with name to value +its expiration time has passed.
ad_set_client_property module name +data Sets a session property with name to value data for the module module. The optional secure flag specifies the property should only be set if the client is authorized for secure access (ad_secure_conn_p is true). There is also an optional -session_id flag to access data from sessions other than the current one.
ad_get_client_property module name -data Gets a session property with name to for the +session_id flag to access data from sessions other than the current one.
ad_get_client_property module name +data Gets a session property with name to for the module module. The optional secure flag specifies the property should only be retrieved if the client is authorized for secure access (ad_secure_conn_p is true). There is also an optional session_id flag to access data from sessions other than the current one.
-SessionTimeout the maximum time in seconds (default 1200) -between requests that are part of the same session
SessionRenew the time in seconds (default 300) between +SessionTimeout the maximum time in seconds (default 1200) +between requests that are part of the same session
SessionRenew the time in seconds (default 300) between reissue of the session cookie. The minimum time that can pass after a session cookie is issued and before it is rejected is (SessionTimeout - SessionRenew). This parameter is used so that only one session_id cookie is set on a single page even if there are multiple images that are being -downloaded.
SessionLifetime the maximum possible lifetime of a -session in seconds (default 604800 = 7 days)
NumberOfCachedSecretTokens the number of secret tokens to +downloaded.
SessionLifetime the maximum possible lifetime of a +session in seconds (default 604800 = 7 days)
NumberOfCachedSecretTokens the number of secret tokens to cache. (default 100)
The pseudorandom number generator used in the OpenACS is cryptographically weak, and depends primarily on the randomness of the ns_rand function @@ -339,15 +339,15 @@ points for the system; these vulnerabilities are currently theoretical in nature. The major cryptographic vulnerability of the system stems from the pseudorandom nature of the random number generators used in the system. -
Cryptographically weak PRNG see -above.
Dependence on sample -SQL command The list of random token that are placed in the secret +
Cryptographically weak PRNG see +above.
Dependence on sample +SQL command The list of random token that are placed in the secret tokens cache is randomly chosen by the Oracle sample command. This command may not be entirely random, so predicting the contents of the secret tokens cache may not -be as difficult as someone may anticipate.
Dependence on -ns_rand The actual token that is +be as difficult as someone may anticipate.
Dependence on +ns_rand The actual token that is chosen from the cache to be used is chosen by a call to -ns_rand.
ad_secure_conn_p +ns_rand.
ad_secure_conn_p As discussed above, the security of the secure sessions authentication system is dependent upon this function.
Prev | Home | Next |
OpenACS 4 Security Requirements | Up | OpenACS 4 Security Notes |