Re: sessions bug?

[JW on t. r. <jw...@ne...>]

> Then there is also the issue of security reading the cookie file(s) on the
> client.  I am not familiar hardly at all with Windows browsers, but I'm
> pretty sure that Netscape stored cookies plaintext (Linux version does
> too).  This is really bad because Windows 9x has no file 
> permissions.  Anybody can open your cookies.txt file and get your password
> in plaintext.  :(  On Linux the permissions on cookies.txt prohibits this,
> and I would assume the same for NT.

This is a problem in many instances.  There are lots of scenarios in which 
cookies can get stolen, permissions on NT or Linux notwithstanding.  It 
just isn't a secure storage mechanism.  Shared PCs are an issue, as is the 
fact that when the cookie file gets erased the plaintext password winds up 
unaccountable somewhere in the unused space of the filesystem.  That 
computer could be sold or reused with the data still on the disk somewhere.

Essentially, any time you see a password in the plain anywhere, red flags 
should go up.

> We can't one way encrypt the password because it needs to be sent to tthe
> IMAP server in plaintext.  So maybe we could do something creative with
> storing the username/pass in the cookie -- like convert to a hex string,
> xor it against something particular for that site the administrator has
> set up in config.php, and then run base64 on it or 
> something.  :)  Definately not secure, but at least it wouldn't be stored
> plaintext on the client.

Hex+XOR is obfuscation, not encryption.  That's just too easy for someone 
to figure out.  :)  This is what I was thinking (DISCLAIMER-- this still 
isnt' ideal, this is only better than what we have now.  :)

An option in the config file is a password that each admin should set to 
something different.  The server uses this password as a static key to 
encrypt data going into cookies.  You could use 3DES or any reasonably 
strong algorithm.  When the server gets the cookie back from the browser it 
decrypts the data with the key and then passes it to IMAP as usual.  This 
isn't ideal from a staunch security point of view (since we still have a 
static key stored plaintext somewhere) but at least this way the plaintext 
lives on the server where the admin has some control.  The config file 
would need to be protected, but that can be accomplished via the types of 
server-side security procedures SquirrelMail already requires (file 
permissions.)  This seems congruent with the existing security model.

Again, not ideal, but it gets plaintext out of the cookie.

Crypto software development is something my company does, so I'm happy to 
contribute expertise wherever necessary.  The only snag is that we haven't 
done PHP, so you might need to bear with us a little on that.

-- 
JW <jw...@ne...>