Hi,
I've just installed Roundcubemail on my server to replace another webmail package. First impression: Very nice work! However, I'm one of those who at least try to review the software they use, and there is one thing that really caught my eye: The user password is stored in the PHP session. I think authentication data should be end to end data, especially if you're running Roundcubemail over https as you should.
The attached, slightly tested patch moves the password from the session into a browser cookie. Thoughts?
Stefan
What security benefit is there by moving it from the session cookie to a non-session cookie?
On Wed, 29 Nov 2006 21:07:03 +0100 (MET), Stefan Rompf stefan@loplof.de wrote:
Hi,
I've just installed Roundcubemail on my server to replace another webmail package. First impression: Very nice work! However, I'm one of those who at least try to review the software they use, and there is one thing that really caught my eye: The user password is stored in the PHP session. I think authentication data should be end to end data, especially if you're running Roundcubemail over https as you should.
The attached, slightly tested patch moves the password from the session into a browser cookie. Thoughts?
Stefan
I wouldn't mind knowing the security risks here if any for either
situation.
Does the user require cookies to use Roundcube, or would this add that
requirement?
On Sat, 02 Dec 2006 07:33:42 +1100, Matt Kaatman
roundcube-dev@matt.kaatman.com wrote:
What security benefit is there by moving it from the session cookie to a
non-session cookie?On Wed, 29 Nov 2006 21:07:03 +0100 (MET), Stefan Rompf
stefan@loplof.de wrote:Hi,
I've just installed Roundcubemail on my server to replace another
webmail package. First impression: Very nice work! However, I'm one of those who at least try to review the software they use, and there is one thing that really caught my eye: The user password is stored in the PHP session. I think authentication data should be end to end data, especially if you're running Roundcubemail over https as you should.The attached, slightly tested patch moves the password from the session into a browser cookie. Thoughts?
Stefan
Stefan Rompf wrote:
Am Samstag, 2. Dezember 2006 00:25 schrieb Chris Fordham:
Does the user require cookies to use Roundcube, or would this add that requirement?
Roundcube already uses (and IMHO requires) cookies, so this does not change anything.
Stefan
Well, honestly Sessions can be changed by the user easily. There are extensions for Firefox that allow just people who are playing around to modify their session. This can either make or break the system.
Cookies, while more difficult to modify, are still modifiable, as well as easily visible.
One thing that I would suggest is that IF you need to keep the password in the session or in a cookie, the password and other vital information is encrypted in some way, either with the mcrypt library or through a user created encryption method. This would be much safer so that if someone did try to view the information, it would be encrypted. Just my suggestion(s).
~Brett
Brett Patterson wrote:
One thing that I would suggest is that IF you need to keep the password in the session or in a cookie, the password and other vital information is encrypted in some way, either with the mcrypt library or through a user created encryption method. This would be much safer so that if someone did try to view the information, it would be encrypted. Just my suggestion(s).
Does this not already happen?
If not, what is the point of this config option:
// this key is used to encrypt the users imap password which is stored // in the session record (and the client cookie if remember password is enabled). // please provide a string of exactly 24 chars. $rcmail_config['des_key'] = 'rcmail-!24ByteDESkey*Str';
I'm a bit under the weather today or I'd go in and see where it's referenced, but this may either be a moot point or already in progress.
Jim
User can modify server side PHP session? How is that possible? Can you provide me any links to read up on?
thanks in advance Brett!
On Sun, 03 Dec 2006 02:46:06 +1100, Brett Patterson brett@bpatterson.net
wrote:
Stefan Rompf wrote:
Am Samstag, 2. Dezember 2006 00:25 schrieb Chris Fordham:
Does the user require cookies to use Roundcube, or would this add that requirement?
Roundcube already uses (and IMHO requires) cookies, so this does not
change anything.Stefan
Well, honestly Sessions can be changed by the user easily. There are
extensions for Firefox that allow just people who are playing around to
modify their session. This can either make or break the system.Cookies, while more difficult to modify, are still modifiable, as well
as easily visible.One thing that I would suggest is that IF you need to keep the password
in the session or in a cookie, the password and other vital information
is encrypted in some way, either with the mcrypt library or through a
user created encryption method. This would be much safer so that if
someone did try to view the information, it would be encrypted. Just my
suggestion(s).~Brett
Am Samstag, den 02.12.2006, 10:46 -0500 schrieb Brett Patterson:
One thing that I would suggest is that IF you need to keep the password in the session or in a cookie, the password and other vital information is encrypted in some way, either with the mcrypt library or through a user created encryption method. This would be much safer so that if someone did try to view the information, it would be encrypted. Just my suggestion(s).
I have been playing around with the matter a while in order to integrate roundcubemail with mediawiki and squirrelmail. After some analysis I found the squirrelmail scheme the safest one and adapted it for my rcmail installation:
- The session is holding a onetime pad, which has exactly the length of
the password. Sqmail gives a bit of an effort to yield an accaptable entropy for the onetime pad.
- The cookie is holding the password encrypted with the onetime pad.
This means, in order to yield the password one has to have access to the current session and the current cookie.
Martin
On Sun, Dec 03, 2006 at 12:46:03AM +0100, Martin Schwartz wrote:
- The session is holding a onetime pad, which has exactly the length of
the password. Sqmail gives a bit of an effort to yield an accaptable entropy for the onetime pad.
- The cookie is holding the password encrypted with the onetime pad.
This means, in order to yield the password one has to have access to the current session and the current cookie.
I like the idea, but what is wrong with storing the password in the session at all? An attacker would need to get access to the server to access it.
If he has this access he is also able to read the onetime pad and the cookie or am I missing something?
Balu
Apparently a Firefox extension can do it somehow... Did someone reply with further info on that yet?
On Tue, 05 Dec 2006 00:42:23 +1100, Thomas -Balu- Walter
list+roundcube-dev@b-a-l-u.de wrote:
On Sun, Dec 03, 2006 at 12:46:03AM +0100, Martin Schwartz wrote:
- The session is holding a onetime pad, which has exactly the length of
the password. Sqmail gives a bit of an effort to yield an accaptable entropy for the onetime pad.
- The cookie is holding the password encrypted with the onetime pad.
This means, in order to yield the password one has to have access to the current session and the current cookie.
I like the idea, but what is wrong with storing the password in the session at all? An attacker would need to get access to the server to access it.
If he has this access he is also able to read the onetime pad and the cookie or am I missing something?
Balu
a quick FUD check here...
On Sat, 2006-12-02 at 10:46 -0500, Brett Patterson wrote:
Well, honestly Sessions can be changed by the user easily. There are extensions for Firefox that allow just people who are playing around to modify their session. This can either make or break the system.
No, users cannot modify their php sessions. Through any tool browser tool. The session itself is server side construct that is link to a session id. The session id can be stored in a cookie or passed through get variables.
Session Hijacking can occur if you find out another users session id and spoof either the PHPSESSID get variable or the cookie.
Cookies, while more difficult to modify, are still modifiable, as well as easily visible.
You should be more concerned about cookies than the php session. You can also use salted cookies with the session id, but if someone is watching the wire can has a valid session id, they can probably get the salted cookie just as easily.
One thing that I would suggest is that IF you need to keep the password in the session or in a cookie, the password and other vital information is encrypted in some way, either with the mcrypt library or through a user created encryption method. This would be much safer so that if someone did try to view the information, it would be encrypted. Just my suggestion(s).
I think you're taking a sum 0 approach, a lot of effort for no real results. If you are truly super paranoid you can start a DH request and page signing session when the user logs in, and continue it for each subsequent ajax request. The you would at least be able to guarantee the identity of the end points per session. OpenID has also solved alot of the problems around distributed authentication system and identity verfication, the 2.0 draft should be finalized soon.... It would be cool to have an email service as an identity provider and uses imap as a pwd backend.
darrel.
-
Brett Patterson -
Chris Fordham -
Darrel O'Pry -
Jim Pingle -
Martin Schwartz -
Matt Kaatman -
Stefan Rompf -
Thomas -Balu- Walter