On Jun 2, 2006, at 10:49 AM, Thomas Bruederli wrote:
richs@whidbey.net wrote:
This patch duplicates Gmail's option of the same name. It stores the username and encrypted password in a cookie (_cuser and _cpass). Anytime you visit RC, you're taken directly to the Inbox.
The patch is available from:
http://www.whidbey.com/richs/rc-rememberme.patch(Please avoid copy+paste, which might garble the localizations).
Nice feature! I like it. Just a few suggestions to make it fit "my conception" of the
RoundCube code:
- Make the forth parameter of rcmail_login optional as well: function rcmail_login($user, $pass, $host=NULL, $remember=FALSE)
Good idea, updated the patch.
- Make sure your changes in the skin templates are XHTML valid. <br> -> <br /> Also make use of CSS styling instead of using <nobr><center> tags.
You caught me. :) I changed it from:
<td colspan=2><br><nobr><center>
to:
<td /><td style="text-align: center; white-space: nowrap;"><br />
- You don't need to alter all localization files. Adding the new labels to the en_US files will do it.
That's excellent. I cut out a few hundred lines from the patch,
leaving only the translated localizations.
As a side effect, you could set "_cuser" and "_cpass" cookies from another web app, or submit them with a form. Remember that you'd
need to mimic Roundcube's "encrypt_passwd" function.After patching, please examine "program/include/main.inc", around
line 701:$cypher = des('rcmail?24BitPwDkeyF**ECB', $pass, 1, 0, NULL);And line 708:
$pass = des('rcmail?24BitPwDkeyF**ECB', base64_decode($cypher), 0, 0, NULL);
I'd recommend changing 'rcmail?24BitPwDkeyF**ECB' to something unique for your site (Could this become a Config option?). For example, 'k2mJs9*l_38qms-CYkja!9Oq'. Otherwise, anyone could decrypt a
password if they had access to cache, cookie, etc.This is a good idea to increase security in any case. There's a little problem with this password encryption and I have a ticket (#1364122) assigned to work on that. I will then make that hash configurable
as well. Generally I don't like the idea of storing passwords on the client's machine. Another idea would be to alter the session management in
order to have sessions with an infinite lifetime. In that case we only have the session key on the client's hard disk and the password is (still) stored in the session record. To achieve this, the cookies need to be sent with an expire date
and the session table has to be extended with an additional col marking this record as a permanent entry. Altering the garbage collection function would be required as well.Security goes first!
I like that idea about extended sessions, but I'd be concerned about
three things; multiple computers, server security, and session
preservation.
A user might access their mail from different places. They may want
to always be remembered at work and at home, but not the library. A
single session might have trouble distinguishing between them
(especially when accessed simultaneously; e.g. coworkers in an office)?
Storing all of the passwords and sessions long-term on the server
might make it easier for an attacker to hijack multiple mailboxes.
Storing them long-term only on each clients computer would spread out
that liability a bit.
If the sessions are PHP sessions, would it be difficult to preserve
them long-term? Load-balanced servers and PHP upgrades might be
trouble?
Gmail authentication seems secure, which happens in 2 stages. First,
you submit your username and password to receive a pair of unique,
encrypted cookies: "SID" and "LSID". If you have "Remember me"
checked, these are stored forever, otherwise they expire.
The "SID" and "LSID" are then submitted back, when necessary, to
receive a session-specific cookie, "GX", which expires when the
session does.
Essentially the SID/LSID essentially become a unique user/pass, based
on the original, to create new sessions. Since the session cookie is
separate, multiple computers are supported.
It sounds like the login, encryption, session and "remember"
mechanisms would all need to be re-written to add that kind of
security. Maybe this is better left for a future version, but I'm
happy to help if we can decide on what should be done.
Rich