[Opensource] Future directions Security follow up...

[Michael Rimov]

Just to followup on the issue of security as discussed with Larry et. 
al.  Here's what we're looking at:

RE: Cookies

Default Security:
1 - Strengthen the encryption of the password cookie. [Provide a random 
number generator to generate a good random key for the sysadmin to put in 
expresso-config]  For those systems, that use login cookies, this will get 
'decent' default security. [AES with a full key is the current government 
standard for encrypting non-classified sensitive data]  I will investigate 
preventing replay attacks.

If SSL is enabled for the system. [Next level up of security]
2 - If cookies are enabled, then CheckLogin will redirect to an SSL session 
to grab the login cookie which is marked 'secure', so it will only travel 
over the wire in an SSL session.  This will make it much harder to 
intercept the cookie through either packet sniffing or XSS attacks.

Final level: No login cookies
Not only will Login controller NOT set any login cookies, checkLogin will 
not accept any login cookies as well.  This forces the user to present 
their credentials with each visit to the site.

RE: Password in session

In general we're looking at integrating with JAAS, so most of the details 
will be dependent on the JAAS implementation:

Default:
JAAS will still contain the user's password in the Principal's 
credential.  Unless you use a 3rd party authentication server, this is the 
way it'll have to work to be able to forward on login requests to remote 
servers on behalf of the user, and it appears this is the way that JAAS was 
designed to work.  This isn't necessarily serious in that the session isn't 
easily crackable externally, only through a disgruntled sysadmin (maybe 
could crack it depending on the session tools available), or a disgruntled 
programmer(could get it with a fair amount of ease).

For higher security:  Since we're going to integrate with JAAS, that'll 
allow us to integrate with 3rd party servers such as a remote Kerberos 
server, or Microsoft NT authentication.  If we do that, then the password 
is stored in memory long enough to pass it onto the authentication 
module.  Once that is done, we receive back an authentication token that we 
store in the session as the Principal's credentials.  Obviously this is 
better from a session standpoint since the token will expire after a given 
period of time.  If we need anything loaded, based upon the user's 
password, we use it upon initial login and discard the password at that point.

Does this make sense to everybody?
						-Mike