security-design.xml
Delivered as text/xml
[ hide source ] | [ make this the default ]
File Contents
<?xml version='1.0' ?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
<!ENTITY % myvars SYSTEM "../variables.ent">
%myvars;
]>
<sect1 id="security-design" xreflabel="OpenACS 4 Security Design">
<title>Security Design</title>
<authorblurb>
<para>By Richard Li and Archit Shah</para>
</authorblurb>
<sect2 id="security-design-essentials">
<title>Essentials</title>
<itemizedlist>
<listitem><para><xref linkend="security-requirements"/></para></listitem>
</itemizedlist>
</sect2>
<sect2 id="security-design-intro">
<title>Introduction</title>
<para>
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
stateless HTTP protocol. This system also provides session level properties
as a generic service to the rest of the OpenACS.
</para>
<para>The atoms used in the implementation:</para>
<itemizedlist>
<listitem><para>Cookies: <ulink url="http://web.mit.edu/rfc/rfc2109.txt">RFC 2109, HTTP
State Management Mechanism</ulink> </para>
<para>Cookies provide client side state. They are used to identify the
user. Expiration of cookies is used to demark the end of a
session.
</para></listitem>
<listitem><para>SHA: <ulink url="http://csrc.nist.gov/fips/fip180-1.txt">SHA-1</ulink> </para>
<para>This secure hash algorithm enables us to digitally sign cookies
which guarantee that they have not been tampered with. It is also used to
hash passwords.
</para></listitem>
<listitem><para>SSL with server authentication: <ulink url="http://home.netscape.com/eng/ssl3/ssl-toc.html">SSL v3</ulink> </para>
<para>SSL provides the client with a guarantee that the server is
actually the server it is advertised as being. It also provides a secure
transport.
</para></listitem>
</itemizedlist>
</sect2>
<sect2 id="security-design-design">
<title>Design</title>
<sect3 id="sessions">
<title>Sessions</title>
<para>
A session is defined as a series of clicks in which no two clicks are
separated by more than some constant. This constant is the parameter
SessionTimeout. Using the expiration time on the signatures of the signed
cookies, we can verify when the cookie was issued and determine if two
requests are part of the same session. It is important to note that the
expiration time set in the cookie protocol is not trusted. Only the time
inserted by the signed cookie mechanism is trusted.
</para>
</sect3>
<sect3 id="authentication">
<title>Authentication</title>
<para>
Two levels of access can be granted: insecure and secure. This grant lasts
for the remainder of the particular session. Secure authentication tokens are
only issued over secured connections.
</para>
<para>One consequence of this security design is that secure tokens are not
automatically issued to users who authenticate themselves over insecure
connections. This means that users will need to reauthenticate themselves
over SSL when performing some action that requires secure authentication.</para>
<para>Although this makes the site less user friendly, this design significantly
increases the security of the system because this ensures that the
authentication tokens presented to a secure section of the web site were not
sniffed. The system is not entirely secure, since the actual authentication
password can be sniffed from the system, after which the sniffer can apply
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.</para>
</sect3>
<sect3 id="authentication-details">
<title>Details</title>
<para>The authentication system issues up to four signed cookies (see below),
with each cookie serving a different purpose. These cookies are:</para>
<informaltable>
<tgroup cols="4">
<tbody>
<row>
<entry><emphasis role="strong">name</emphasis></entry>
<entry><emphasis role="strong">value</emphasis></entry>
<entry><emphasis role="strong">max-age</emphasis></entry>
<entry><emphasis role="strong">secure?</emphasis></entry>
</row>
<row>
<entry>ad_session_id</entry>
<entry>session_id,user_id</entry>
<entry>SessionTimeout</entry>
<entry>no</entry>
</row>
<row>
<entry>ad_user_login</entry>
<entry>user_id</entry>
<entry>Infinity</entry>
<entry>no</entry>
</row>
<row>
<entry>ad_user_login_secure</entry>
<entry>user_id,random</entry>
<entry>Infinity</entry>
<entry>yes</entry>
</row>
<row>
<entry>ad_secure_token</entry>
<entry>session_id,user_id,random</entry>
<entry>SessionLifetime</entry>
<entry>yes</entry>
</row>
</tbody></tgroup></informaltable>
<itemizedlist>
<listitem><para>ad_session_id</para>
<itemizedlist>
<listitem><para>reissued on any hit separated by more than SessionRenew seconds from the
previous hit that received a cookie</para></listitem>
<listitem><para>is valid only for SessionTimeout seconds</para></listitem>
<listitem><para>is the canonical source for the session ID in ad_conn</para></listitem>
</itemizedlist>
</listitem>
<listitem><para>ad_user_login</para>
<itemizedlist>
<listitem><para>is used for permanent logins</para></listitem>
</itemizedlist>
</listitem>
<listitem><para>ad_user_login_secure</para>
<itemizedlist>
<listitem><para>is used for permanent secure logins</para></listitem>
<listitem><para>contains random garbage (ns_time) to prevent attack against the secure
hash</para></listitem>
</itemizedlist>
</listitem>
<listitem><para>ad_secure_token
</para>
<itemizedlist>
<listitem><para>is a session-level cookie from the browser's standpoint</para></listitem>
<listitem><para>its signature expires in SessionLifetime seconds</para></listitem>
<listitem><para>contains random garbage (ns_time) to prevent attack against the secure
hash</para></listitem>
<listitem><para>user_id is extraneous</para></listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="authentication-process">
<title>Authentication Process</title>
<para>The Tcl function (<computeroutput>sec_handler</computeroutput>) is called by the request
processor to authenticate the user. It first checks the
<computeroutput>ad_session_id</computeroutput> cookie. If there is no valid session in progress,
a new session is created with <computeroutput>sec_setup_session</computeroutput>. If the user
has permanent login cookies (<computeroutput>ad_user_login</computeroutput> and
<computeroutput>ad_user_login_secure</computeroutput>), then they are looked at to determine what
user the session should be authorized as. Which cookie is examined is
determined by whether or not the request is on a secure connection. If
neither cookie is present, then a session is created without any
authentication. If the <computeroutput>ad_session_id</computeroutput> cookie is valid, the
user_id and session_id are pulled from it and put into ad_conn.</para>
</sect3>
<sect3 id="secure-connections">
<title>Authenticating Secure Connections</title>
<para>Secure connections are authenticated slightly differently. The function
<computeroutput>ad_secure_conn_p</computeroutput> is used to determine whether or not the URL
being accessed is requires a secure login. The function simply checks if the
location begins with "https". (This is safe because the location is
set during the server initialization.)</para>
<para>If secure authentication is required, the <computeroutput>ad_secure_token</computeroutput>
cookie is checked to make sure its data matches the data stored in
<computeroutput>ad_session_id</computeroutput>. This is true for all pages except those that are
part of the login process. On these pages, the user can not yet have received
the appropriate <computeroutput>ad_secure_token</computeroutput> cookie, so no check against it
is performed. The set of pages that skip that processing are determined by
determined by <computeroutput>ad_login_page</computeroutput>. Since the
<computeroutput>ad_secure_token</computeroutput> cookie is a session cookie, it is deleted by the
browser when the browser exits. Since an attacker could conceivably store the
secure cookie in a replay attack (since expiration date is not validated),
the data in the secure cookie is never used to set any data in ad_conn;
user_id and session_id is set from the ad_session_id cookie.</para>
<para>It is important to note that the integrity of secure authentication rests
on the two Tcl function <computeroutput>ad_secure_conn_p</computeroutput> and
<computeroutput>ad_login_page</computeroutput>. If <computeroutput>ad_secure_conn_p</computeroutput> is false, secure
authentication is not required. If <computeroutput>ad_login_page</computeroutput> is false,
secure authentication is not required.</para>
</sect3>
<sect3 id="login-process">
<title>Login Process</title>
<para>The Tcl function <computeroutput>ad_user_login</computeroutput> does two things. First it
performs the appropriate manipulation of the permanent login cookies, and
then it updates the current session to reflect the new user_id. The
manipulation of the permanent login cookies is based on 3 factors:</para>
<itemizedlist>
<listitem><para>previous login: other user, same user</para></listitem>
<listitem><para>permanent: was a permanent login requested?</para></listitem>
<listitem><para>secure: is this a secure connection?</para></listitem>
</itemizedlist>
<para>
Both the secure and insecure permanent login cookie can have one of three
actions taken on it:
</para>
<itemizedlist>
<listitem><para>set: cookie with no expiration is set</para></listitem>
<listitem><para>delete: set to "" with max age of 0, so it is expired
immediately</para></listitem>
<listitem><para>nothing: if the cookie is present, it remains</para></listitem>
</itemizedlist>
<para>
The current state of the permanent login cookies is not taken into account
when determining the appropriate action.
</para>
<informaltable>
<tgroup cols="5">
<tbody>
<row>
<entry><emphasis role="strong">previous login state</emphasis></entry>
<entry><emphasis role="strong">permanent login requested</emphasis></entry>
<entry><emphasis role="strong">secure connection</emphasis></entry>
<entry><emphasis role="strong">action on insecure</emphasis></entry>
<entry><emphasis role="strong">action on secure</emphasis></entry>
</row>
<row>
<entry>other</entry>
<entry>y</entry>
<entry>y</entry>
<entry>set</entry>
<entry>set</entry>
</row>
<row>
<entry>same</entry>
<entry>y</entry>
<entry>y</entry>
<entry>set</entry>
<entry>set</entry>
</row>
<row>
<entry>other</entry>
<entry>y</entry>
<entry>n</entry>
<entry>set</entry>
<entry>delete</entry>
</row>
<row>
<entry>same</entry>
<entry>y</entry>
<entry>n</entry>
<entry>set</entry>
<entry>nothing</entry>
</row>
<row>
<entry>same</entry>
<entry>n</entry>
<entry>y</entry>
<entry>nothing</entry>
<entry>delete</entry>
</row>
<row>
<entry>other</entry>
<entry>n</entry>
<entry>y</entry>
<entry>delete</entry>
<entry>delete</entry>
</row>
<row>
<entry>other</entry>
<entry>n</entry>
<entry>n</entry>
<entry>delete</entry>
<entry>delete</entry>
</row>
<row>
<entry>same</entry>
<entry>n</entry>
<entry>n</entry>
<entry>delete</entry>
<entry>delete</entry>
</row>
</tbody></tgroup></informaltable>
<para><computeroutput>ad_user_login</computeroutput>
calls<computeroutput>sec_setup_session</computeroutput> which actually calls
<computeroutput>sec_generate_session_id_cookie</computeroutput> to generate the
new cookie with refer to the appropriate user_id. If the connection is secure
the <computeroutput>ad_secure_token</computeroutput> cookie is generated by a
call to <computeroutput>sec_generate_secure_token_cookie</computeroutput>. This
function is only called from
<computeroutput>sec_setup_session</computeroutput>. Only
<computeroutput>sec_handler</computeroutput> and
<computeroutput>sec_setup_session</computeroutput> call
<computeroutput>sec_generate_session_id_cookie</computeroutput>.
</para>
<para><computeroutput>ad_user_logout</computeroutput> logs the user out by deleting all 4 cookies
that are used by the authentication system.</para>
</sect3>
<sect3 id="session-creation">
<title>Session Creation</title>
<para>The creation and setup of sessions is handled in
<computeroutput>sec_setup_session</computeroutput>, which is called either to
create a new session from <computeroutput>sec_handler</computeroutput> or from
<computeroutput>ad_user_login</computeroutput> when there is a change in
authorization level. The session management code must do two things: ensure that
session-level data does not float between users, and update the users table
which has columns for <computeroutput>n_sessions</computeroutput>,
<computeroutput>last_visit</computeroutput>, and
<computeroutput>second_to_last_visit</computeroutput>.</para>
<para>If there is no session already setup on this hit, a new session is
created. This happens when <computeroutput>sec_setup_session</computeroutput> is
called from <computeroutput>sec_handler</computeroutput>. If the login is from a
user to another user, a new session is created, otherwise, the current session
is continued, simply with a higher authorization state. This allows for data
associated with a session to be carried over when a user logs in.</para>
<para>The users table is updated by
<computeroutput>sec_update_user_session_info</computeroutput> which is called
when an existing session is assigned a nonzero user_id, or when a session is
created with a nonzero user_id.</para>
</sect3>
<sect3 id="passwords">
<title>Passwords</title>
<para><computeroutput>ad_user_login</computeroutput> assumes a password check has already been
performed (this will change in the future). The actual check is done by
<computeroutput>ad_check_password</computeroutput>. The database stores a salt and a hash of the
password concatenated with the salt. Updating the password
(<computeroutput>ad_change_password</computeroutput>) simply requires getting a new salt
(ns_time) concatenating and rehashing. Both the salt and the hashed password
field are updated.</para>
</sect3>
<sect3 id="performance-enhancements">
<title>Performance Enhancements</title>
<para>A session is labeled by a session_id sequence. Creating a session merely
requires incrementing the session_id sequence. We do two things to improve the
performance of this process. First, sequence values are precomputed and cached
in the Oracle SGA. In addition, sequence values are incremented by 100 with each
call to nextval. These sequences values are cached on a per-thread basis. The
cost of allocating a new session thus becomes the cost of executing an incr Tcl
command per thread. This minimizes lock contention for the session ID sequence
and also minimizes the number of DB requests, since each thread can allocate 100
sessions before requiring another DB hit. This cache works by keeping two
counters: <computeroutput>tcl_max_value</computeroutput> and
<computeroutput>tcl_current_sequence_id</computeroutput>. When
<computeroutput>tcl_current_sequence_id</computeroutput> is greater than
<computeroutput>tcl_max_value</computeroutput> a new value is requested from the
db and <computeroutput>tcl_max_value</computeroutput> is incremented by
100. This is done on a per-thread basis so that no locking is required.
</para>
<para>In addition, two procedures are dynamically generated at startup in
<computeroutput>security-init.tcl</computeroutput>. These two procedures use
<computeroutput>ad_parameter</computeroutput> to obtain the constant value of a given parameter;
these values are used to dynamically generate a procedure that returns a
constant. This approach avoids (relatively) expensive calls to
<computeroutput>ad_parameter</computeroutput> in <computeroutput>sec_handler</computeroutput>. The impact of this
approach is that these parameters cannot be dynamically changed at run time
and require a server restart.</para>
</sect3>
<sect3 id="session-properties">
<title>Session Properties</title>
<para>
Session properties are stored in a single table that maps session IDs to
named session properties and values. This table is periodically purged. For
maximum performance, the table is created with nologging turned on and new
extents are allocated in 50MB increments to reduce fragmentation. This table
is swept periodically by <computeroutput>sec_sweep_session</computeroutput> which removes
sessions whose first hit was more than SessionLifetime seconds (1 week by
default) ago. Session properties are removed through that same process with
cascading delete.
</para>
</sect3>
<sect3 id="secure-session-properties">
<title>Secure Session Properties</title>
<para>Session properties can be set as secure. In this case,
<computeroutput>ad_set_client_property</computeroutput> will fail if the connection is not
secure. <computeroutput>ad_get_client_property</computeroutput> will behave as if the property
had not been set if the property was not set securely.</para>
</sect3>
<sect3 id="digital-signatures">
<title>Digital Signatures & Signed Cookies</title>
<para>
Signed cookies are implemented using the generic secure digital signature
mechanism. This mechanism guarantees that the user can not tamper with (or
construct a value of his choice) without detection. In addition, it provides
the optional facility of timing out the signature so it is valid for only a
certain period of time. This works by simply including an expiration time as
part of the value that is signed.
</para>
<para>The signature produced by <computeroutput>ad_sign</computeroutput> is the Tcl list of
<computeroutput>token_id,expire_time,hash</computeroutput>, where hash =
SHA1(value,token_id,expire_time,secret_token). The secret_token is a forty
character randomly generated string that is never sent to any user agent. The
scheme consists of one table:</para>
<programlisting>
create table secret_tokens (
token_id integer
constraint secret_tokens_token_id_pk primary key,
token char(40),
token_timestamp sysdate
);
</programlisting>
<para><computeroutput>ad_verify_signature</computeroutput> takes a value and a signature and
verifies that the signature was generated using that value. It works simply
by taking the token_id and expire_time from the signature, and regenerating
the hash using the supplied value and the secret_token corresponding to the
token_id. This regenerated hash is compared to the hash extracted from the
supplied signature. The expire_time is also verified to be greater than the
current time. An expire_time of 0 is also allowed, as it indicates no time
out on the signature.</para>
<para>Signed cookies include in their RFC2109 VALUE field a Tcl list of the
value and the signature. In addition to the expiration of the digital
signature, RFC 2109 specifies an optional max age that is returned to the
client. For most cookies, this max age matches the expiration date of the
cookie's signature. The standard specifies that when the max age is not
included, the cookie should be "discarded when the user agent
exits." Because we can not trust the client to do this, we must specify
a timeout for the signature. The SessionLifetime parameter is used for this
purpose, as it represents the maximum possible lifetime of a single
session.</para>
<para>RFC 2109 specifies this optional "secure" parameter which
mandates that the user-agent use "secure means" to contact the
server when transmitting the cookie. If a secure cookie is returned to the
client over https, then the cookie will never be transmitted over insecure
means.</para>
<sect4 id="signature-performance">
<title>Performance</title>
<para>Performance is a key goal of this implementation of signed cookies. To
maximize performance, we will use the following architecture. At the lowest
level, we will use the <computeroutput>secret_tokens</computeroutput> table as the canonical set
of secret tokens. This table is necessary for multiple servers to maintain
the same set of secret tokens. At server startup, a random subset of these
secret tokens will be loaded into an ns_cache called
<computeroutput>secret_tokens</computeroutput>. When a new signed cookie is requested, a random
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.</para>
<para>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:</para>
<itemizedlist>
<listitem><para><emphasis role="strong">LRU cache</emphasis> 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.</para></listitem>
<listitem><para><emphasis role="strong">signature cache</emphasis> 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.</para></listitem>
</itemizedlist>
<para>
The per-thread cache functions as an L1 cache that indiscriminately caches
all secret tokens. Note that this is <emphasis role="strong">not</emphasis> an LRU cache
because there is no cache eviction policy per se -- the cache is cleared when
the thread is destroyed by AOLserver.
</para>
</sect4>
<sect4 id="signature-security">
<title>Security</title>
<para>Storing information on a client always presents an additional security
risk.</para>
<para>Since we are only validating the information and not trying to protect it
as a secret, we don't use salt. Cryptographic salt is useful if you are
trying to protect information from being read (e.g., hashing passwords).</para>
</sect4>
</sect3>
<sect3 id="external-ssl">
<title>External SSL</title>
<para>
External SSL mechanisms (firewall, dedicated hardware, etc.) can be used by
creating two pools of AOLservers. In one pool the servers should be
configured with the location parameter of nssock module set to
"https://yourservername". The servers in the other pool are
configured as normal. The external SSL agent should direct SSL queries to the
pool of secure servers, and it should direct non-SSL queries to the insecure
servers.
</para>
</sect3>
<sect3 id="PRNG">
<title>PRNG</title>
<para>
The pseudorandom number generator depends primarily on ns_rand, but is also
seeded with ns_time and the number of page requests served since the server
was started. The PRNG takes the SHA1(seed,ns_rand,ns_time,requests,clicks),
and saves the first 40 bits as the seed for the next call to the PRNG in a
thread-persistent global variable. The remaining 120 bits are rehashed to
produce 160 bits of output.
</para>
</sect3>
</sect2>
<sect2 id="security-design-api">
<title>API</title>
<sect3 id="login-password-api">
<title>Login/Password</title>
<para>
<emphasis role="strong">ad_user_login <emphasis>user_id</emphasis></emphasis> Logs the user in as user
<emphasis>user_id</emphasis>. Optional forever flag determines whether or not permanent
cookies are issued.
</para>
<para><emphasis role="strong">ad_user_logout</emphasis> Logs the user out.</para>
<para><emphasis role="strong">ad_check_password <emphasis>user_id</emphasis> <emphasis>password</emphasis></emphasis>
returns 0 or 1.</para>
<para><emphasis role="strong">ad_change_password <emphasis>user_id</emphasis> <emphasis>new
password</emphasis></emphasis></para>
</sect3>
<sect3 id="signature-api">
<title>Digital Signatures and Signed Cookies</title>
<para>
<emphasis role="strong">ad_sign <emphasis>value</emphasis></emphasis> Returns the digital signature of this
value. Optional parameters allow for the specification of the <emphasis>secret</emphasis>
used, the <emphasis>token_id</emphasis> used and the <emphasis>max_age</emphasis> for the signature.
<emphasis role="strong">ad_verify_signature <emphasis>value</emphasis> <emphasis>signature</emphasis></emphasis>Returns
1 or 0 indicating whether or not the signature matches the value specified.
The <emphasis>secret</emphasis> parameter allows for specification of a different secret
token to be used. </para>
<para>
<emphasis role="strong">ad_set_signed_cookie <emphasis>name</emphasis> <emphasis>data</emphasis></emphasis> Sets a
signed cookie <emphasis>name</emphasis> with value <emphasis>data</emphasis>. </para>
<para><emphasis role="strong">ad_get_signed_cookie <emphasis>name</emphasis></emphasis> Gets the signed cookie
<emphasis>name</emphasis>. It raises an error if the cookie has been tampered with, or if
its expiration time has passed.</para>
</sect3>
<sect3 id="session-property-api">
<title>Session Properties</title>
<para><emphasis role="strong">ad_set_client_property <emphasis>module</emphasis> <emphasis>name</emphasis>
<emphasis>data</emphasis></emphasis> Sets a session property with <emphasis>name</emphasis> to value
<emphasis>data</emphasis> for the module <emphasis>module</emphasis>. The optional secure flag
specifies the property should only be set if the client is authorized for
secure access (<computeroutput>ad_secure_conn_p</computeroutput> is true). There is also an optional
<emphasis>session_id</emphasis> flag to access data from sessions other than the current one.</para>
<para><emphasis role="strong">ad_get_client_property <emphasis>module</emphasis> <emphasis>name</emphasis>
<emphasis>data</emphasis></emphasis> Gets a session property with <emphasis>name</emphasis> to for the
module <emphasis>module</emphasis>. The optional secure flag specifies the property
should only be retrieved if the client is authorized for secure access
(<computeroutput>ad_secure_conn_p</computeroutput> is true). There is also an optional
<emphasis>session_id</emphasis> flag to access data from sessions other than the current one.</para>
</sect3>
<sect3 id="parameters">
<title>Parameters</title>
<para>
<emphasis role="strong">SessionTimeout</emphasis> the maximum time in seconds (default 1200)
between requests that are part of the same session </para>
<para><emphasis role="strong">SessionRenew</emphasis> 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.</para>
<para><emphasis role="strong">SessionLifetime</emphasis> the maximum possible lifetime of a
session in seconds (default 604800 = 7 days)</para>
<para><emphasis role="strong">NumberOfCachedSecretTokens</emphasis> the number of secret tokens to
cache. (default 100)</para>
</sect3>
</sect2>
<sect2 id="security-design-future">
<title>Future Improvements</title>
<sect3 id="PRNG-impl">
<title>PRNG implementation</title>
<para>
The pseudorandom number generator used in the OpenACS is cryptographically weak,
and depends primarily on the randomness of the <computeroutput>ns_rand</computeroutput> function
for its randomness. The implementation of the PRNG could be substantially
improved.
</para>
</sect3>
<sect3 id="ad_user_login">
<title><computeroutput>ad_user_login</computeroutput></title>
<para>
Add a password argument. It is non-optimal to make the default behavior to
assume that the password was provided.
</para>
</sect3>
<sect3 id="secret-tokens">
<title>Secret Tokens</title>
<para>
The secret tokens pool is currently static. Ideally, this pool should be
changed on a random but regular basis, and the number of secret_tokens
increased as the number of users come to the web site.
</para>
<para>Since the security of the entire system depends on the secret tokens pool,
access to the secret tokens table should be restricted and accessible via a
strict PL/SQL API. This can be done by revoking standard SQL permissions on
the table for the AOLserver user and giving those permissions to a PL/SQL
package.</para>
</sect3>
<sect3 id="robots">
<title>Robots</title>
<para>
Deferring session to creation until the second hit from a browser seems to be
a good way of preventing a lot of overhead processing for robots. If we do
this, send cookie on first hit to test if cookies are accepted, then actually
allocate on second hit. To preserve a record of the first hit of the session,
just include any info about that first hit in the probe cookie sent. Look at
how usca_p (user session cookie attempted) is used in OpenACS 3.x ecommerce.
</para>
</sect3>
<sect3 id="client-property-future">
<title>Client properties</title>
<para>
Currently there are only session properties. Because sessions have a maximum
life, properties have a maximum life. It would be nice to expand the
interface to allow for more persistent properties. In the past, there was a
sec_browser_properties table that held permanent properties about each unique
visitor (for logged-in users, these are just user properties). This was
unscalable because there was no way to delete these properties, and the table
tended to grow to millions of rows. It would be nice to view browser and
session properties as two types of client properties, but with different
deletion patterns (there are other differences as well, browser properties
can be shared between concurrent sessions). The applications should have
control over the deletion patterns, but should not be able to ignore the
amount of data stored.
</para>
</sect3>
<sect3 id="session-information">
<title>Session information</title>
<para>
It would be nice to keep some info about sessions: first hit, last hit, and
URLs visited come to mind. Both logging and API for accessing this info would
be nice. WimpyPoint is an application that already wants to use this
information to show how long the current presentation has been viewed. The
right way may be to put the session_id into the access log and use log
analyzers (leaving it in server memory for applications to access). Putting
it into the database at all is probably too big a hammer. Certainly putting
it into the database on every hit is too big a hammer.
</para>
</sect3>
<sect3 id="cookieless-sessions">
<title>Cookieless Sessions</title>
<para>Two trends drive the requirement for removing cookie dependence. WAP
browsers that do not have cookies, and public perceptions of cookies as an
invasion of privacy. The rely on the cookies mechanism in HTTP to distinguish
one request from the next, and we trust it to force requests from the same
client to carry the same cookie headers. The same thing can be accomplished by
personalizing the URLs sent back to each browser. If we can store an identifier
in the URL and get it back on the next hit, the sessions system would continue
to work.</para>
<para>Problems that arise:
<itemizedlist>
<listitem><para>URL sharing could be dangerous. If I happen to be browsing Amazon
while logged in and I email a friend, he could conceivably receive it and follow
it before my session has expired, gaining all of the privileges I
had.</para></listitem>
<listitem><para>User-entered URLs are harder to handler. If a user is in the middle of
a session and then types in the URL of some page, he could be kicked out of his
session.</para></listitem>
</itemizedlist>
Both of these problems can be mitigated by doing detection of cookie support
(see the section on robot detection). To help deal with the first problem, One
could also make the restriction that secure sessions are only allowed over
cookied HTTP.</para>
</sect3>
</sect2>
<sect2 id="security-design-vulnerability">
<title>Vulnerability Analysis</title>
<para>
This section is not meant to be a comprehensive analysis of the
vulnerabilities of the security system. Listed below are possible attack
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.
</para>
<itemizedlist>
<listitem><para><emphasis role="strong">Cryptographically weak PRNG</emphasis> see
above.</para></listitem>
<listitem><para><emphasis role="strong">Dependence on <computeroutput>sample</computeroutput>
SQL command</emphasis> The list of random token that are placed in the secret
tokens cache is randomly chosen by the Oracle
<computeroutput>sample</computeroutput> 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.</para></listitem>
<listitem><para><emphasis role="strong">Dependence on
<computeroutput>ns_rand</computeroutput></emphasis> The actual token that is
chosen from the cache to be used is chosen by a call to
<computeroutput>ns_rand</computeroutput>.</para></listitem>
<listitem><para><emphasis role="strong"><computeroutput>ad_secure_conn_p</computeroutput></emphasis>
As discussed above, the security of the secure sessions authentication system is
dependent upon this function.</para></listitem> </itemizedlist>
</sect2>
</sect1>
