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.7 -r1.8 --- openacs-4/packages/acs-core-docs/www/security-design.html 10 Aug 2002 20:07:21 -0000 1.7 +++ openacs-4/packages/acs-core-docs/www/security-design.html 30 Nov 2002 17:16:24 -0000 1.8 @@ -1,10 +1,10 @@ -OpenACS 4 Security Design

OpenACS 4 Security Design

+OpenACS 4 Security Design

OpenACS 4 Security Design

by Richard Li, Archit Shah
- OpenACS docs are written by the named authors, but may be edited - by OpenACS documentation staff. -

Introduction

+ OpenACS docs are written by the named authors, but may be edited + by OpenACS documentation staff. +

Introduction

This document explains security model design for OpenACS 4. The security system with the OpenACS core must authenticate users in both secure and insecure environments. In addition, this subsystem provides sessions on top of the @@ -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.

Details

The authentication system issues up to four signed cookies (see below), -with each cookie serving a different purpose. These cookies are:

namevaluemax-agesecure?
ad_session_idsession_id,user_idSessionTimeoutno
ad_user_loginuser_idInfinityno
ad_user_login_secureuser_id,randomInfinityyes
ad_secure_tokensession_id,user_id,randomSessionLifetimeyes
  • 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:

      namevaluemax-agesecure?
      ad_session_idsession_id,user_idSessionTimeoutno
      ad_user_loginuser_idInfinityno
      ad_user_login_secureuser_id,randomInfinityyes
      ad_secure_tokensession_id,user_id,randomSessionLifetimeyes
      • 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

      Authentication Process

      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 statepermanent login requestedsecure connectionaction on insecureaction on secure
    otheryysetset
    sameyysetset
    otherynsetdelete
    sameynsetnothing
    samenynothingdelete
    othernydeletedelete
    othernndeletedelete
    samenndeletedelete

    ad_user_login +

    previous login statepermanent login requestedsecure connectionaction on insecureaction on secure
    otheryysetset
    sameyysetset
    otherynsetdelete
    sameynsetnothing
    samenynothingdelete
    othernydeletedelete
    othernndeletedelete
    samenndeletedelete

    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.

    Security

    Storing information on a client always presents an additional security @@ -234,41 +234,41 @@ thread-persistent global variable. The remaining 120 bits are rehashed to produce 160 bits of output.

API

Login/Password

-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

Digital Signatures and Signed Cookies

-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

Digital Signatures and Signed Cookies

+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.

Session Properties

ad_set_client_property module name -data Sets a session property with name to value +its expiration time has passed.

Session Properties

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.

Parameters

-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)

Future Improvements

PRNG implementation

The pseudorandom number generator used in the OpenACS is cryptographically weak, and depends primarily on the randomness of the ns_rand function @@ -339,17 +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.

+dependent upon this function.

View comments on this page at openacs.org