Forgot your password?
New user?
Document Actions
#48: Use session instead of cookie plugin to store PAS authentication
- Contents
Use SessionCrumblers session authentication plugin to get secure session based authentication without base64 password cookies.
- Proposed by
- Simon Eisenmann
- Seconded by
- Alexander Limi
- Proposal type
- Architecture
- Repository branch
- plip48-bundle
- State
- rejected
Motivation
Currently PlonePAS uses either basic or cookie auth to store the authentication credentials. PluggableAuthenticationService comes with a session auth plugin which stores the credentials inside the session.
Why?: Cookies are used to remember the authentication credentials in Plone. On login PAS simply stores zopes basic auth into a cookie. This means that the users login credentials (userid + password) is basically transmitted in plain text on every single request. Also the login data is stored on the local harddisk.
In continuation of the CookieCrumbler which has been replaced by PAS -> cookie plugin Plone should ship a similar plugin like implemented for Plone 2 with the SessionCrumbler product.
By replacing cookie auth with session auth we get a more secure implementation, cause the password is only transmitted once while the login itself. The password is stored inside the users session which lives in the servers memory. The only thing transmitted along with every request is the session id inside a cookie.
As sessions are not really meant for storing security sensitive information, The session auth plugin should implement a secure container class which prevents access to login credentials from untrusted code. This does not make it secure if you are strict, but it makes it a lot more secure than the current cookie solution. This secure container is not part of the default session plugin of PAS at the moment.Proposal
- Replace credentials_cookie_auth with credentials_session_auth to get rid of plain text password transfer on any request.
- Build a session_auth plugin similar into SessionCrumbler.
- Use this plugin on portal creation (PlonePAS.Extensions.Install)
Implementation
- SessionCrumbler contains a PAS plugin for session auth. (http://longsleep.org/projects/sessioncrumbler)
- PlonePAS should use this plugin for authentication.
Risks
- Sessions require memory
- The Session storage (zopes TemporaryStorage) has not been very "stable" with lots of paralel requests in the past.
- When using multiple ZEO clients for a single portal, you need either share the session storage between all clients or keep a mapping which makes sure one session always ends up at the same ZEO client (loadbalancers can do that easily).
- Default Zope session limit is set to 1000. This means without reconfiguration we are limited to 1000 parallel logged in users.
- Still requires a cookie (for session id).
- Sessions do have a timeout. This means if the user does not do anything, the login session will expire. This is a major functionality change.
- Sessions are gone on ZEO client restarts. This means logins are lost when the instance is restared. This is another major change.
Progress log
- Implemented PAS plugin inside the SessionCrumbler product.
- Modified PlonePAS installer to use SessionCrumblers plugin.
Would love to see this in 3.0
Posted by
Alexander Limi
at
August 10, 2006 - 21:23
There are a lot of small things we can do to make the default setup in Plone a bit more sane, security-wise. This is one of them.
Simon, are you up for championing this into 3.0? Review bundle deadline is end of August. :)
(The other is to have a checkbox in the prefs that forces the login form to be https for those who have setups like that)
Simon, are you up for championing this into 3.0? Review bundle deadline is end of August. :)
(The other is to have a checkbox in the prefs that forces the login form to be https for those who have setups like that)
Ok ..
Posted by
Simon Eisenmann
at
August 10, 2006 - 21:59
What needs to be done to get it into the review bundle? I think the main work is basically to get rid of the hardcoded "cookie_crumbler" id inside some of the templates.
Creating a review bundle
Posted by
Alexander Limi
at
August 11, 2006 - 08:59
Every PLIP needs a review bundle to be considered for inclusion in a release.
Essentially, this is a bundle that checks out Plone with any special branches needed for the framework team to test the functionality.
For an example, see:
http://dev.plone.org/plone/browser/review/plip127-fieldsets
Essentially, this is a bundle that checks out Plone with any special branches needed for the framework team to test the functionality.
For an example, see:
http://dev.plone.org/plone/browser/review/plip127-fieldsets
Seems most of the hard work is already done
Posted by
Alexander Limi
at
August 11, 2006 - 19:11
Have a look at http://svn.plone.org/svn/collective/httpslogin/trunk/
Please coordinate with Daniel Nouri and Reinout van Rees, let's get this into 3.0! :)
Please coordinate with Daniel Nouri and Reinout van Rees, let's get this into 3.0! :)
Interaction with Squid
Posted by
Geoff Davis
at
September 1, 2006 - 12:48
Keep in mind that if you want smart proxy cache behavior, there needs to be some way for the cache to determine if you are authenticated or not. CacheFu uses a squid helper script that checks the cookies and bypasses the cache when you are authenticated. If you switch to sessions, you'll lose the ability to do this unless you stick in some kind of cookie-based flag for squid. The cookie need not contain anything private -- it just needs to be set when you log in and deleted when you log out.
Taken care of
Posted by
Justin Ryan
at
October 3, 2006 - 22:14
I believe Wichert or someone committed a fix to svn trunk of CacheFu recently which also recognizes the session cookie.
Why not simply use PAS' SessionAuthHelper?
Posted by
Jan Hackel
at
November 2, 2006 - 11:09
Correct me if I am mistaken, but does not the SessionAuthHelper Plugin that come bundled with PAS do exactly the desired thing? I tried it in my Plone installation an could not monitor any __ac cookie send over the wire anymore! Is there an incompatibility I am not aware of?
Not production quality
Posted by
Simon Eisenmann
at
November 2, 2006 - 11:29
No incompatibilty. Just try to use that plugin on a high traffic site and your page will explode. Sessioncrumblers implementation is far more advanced and provides an own PAS plugin. Noone should be using PAS default session plugin in production. Its just an example for PAS.
SessionCrumbler plugin ready for use?
Posted by
Jan Hackel
at
November 2, 2006 - 12:26
Is the SessionCrumbler repository version (since 0.2 does not contain the plugin) ready to use then?
You mention that a high traffic site would "explode" when using SessionAuthHelper. Can you explain that further? As far as I see, SessionAuthHelper merely puts the credentials in two fields inside REQUEST.SESSION. SessionCrumbler's pasauthhelper also uses request.session. What is the hidden impact of the SessionAuthHelper implementation?
You mention that a high traffic site would "explode" when using SessionAuthHelper. Can you explain that further? As far as I see, SessionAuthHelper merely puts the credentials in two fields inside REQUEST.SESSION. SessionCrumbler's pasauthhelper also uses request.session. What is the hidden impact of the SessionAuthHelper implementation?
Session only created when required with SessionCrumbler
Posted by
Simon Eisenmann
at
November 2, 2006 - 13:00
The repository version is supposed to work well. SessionCrumbler only creates a session when really required and stores the credentials inside a secure container which prevents untrusted access. The main difference is that anoymous users do not get a session (which is very important to avoid conflict errors).
Re: PLIP #48: Session instead of cookie to store PAS authentication
Posted by
Laurence Rowe
at
February 27, 2007 - 13:40
(Reply to thread on plone-devel. Posted here for completeness)
OK, trying to clear things up a little:
* Presently the username:password is bas64 encoded as the __ac cookie
* "Cookies are either stored in memory (session cookies) or placed on your hard disk (persistent cookies)." http://support.microsoft.com/kb/260971
* This is a session cookie
* Any browser that writes a session cookie to disk must be brain dead. (excepting memory being swapped out of course, but that would be like finding a needle in a haystack, and if the hacker can do that they could probably install a keylogger)
* That means we have the same expectation of security as HTTP basic auth
* To secure this you need to use HTTPS on every request (apache, easy)
* Sessions are not used in Plone out of the box.
* Zope sessions are "notoriously heavy" (alecm) - http://lists.plone.org/pipermail/framework-team/2006-September/000590.html
* They also complicate ZEO setup, you either need to ensure users end up on the same zope client (with pound or similar) or mount the temporary storage over ZEO (slow).
I'm -0 on including SessionCrumbler and -10 on enabling it by default.
If you want to stop passwords being sent across the ether unnecessarily then the mod_auth_tkt approach is probably better, using cryptographic hashing based on a secret known only to the server. Implementing that scheme for PAS should be fairly simple (there is already some python code to construct cookies)
If you want security you really should encrypt logged in sessions over SSL.
Laurence
OK, trying to clear things up a little:
* Presently the username:password is bas64 encoded as the __ac cookie
* "Cookies are either stored in memory (session cookies) or placed on your hard disk (persistent cookies)." http://support.microsoft.com/kb/260971
* This is a session cookie
* Any browser that writes a session cookie to disk must be brain dead. (excepting memory being swapped out of course, but that would be like finding a needle in a haystack, and if the hacker can do that they could probably install a keylogger)
* That means we have the same expectation of security as HTTP basic auth
* To secure this you need to use HTTPS on every request (apache, easy)
* Sessions are not used in Plone out of the box.
* Zope sessions are "notoriously heavy" (alecm) - http://lists.plone.org/pipermail/framework-team/2006-September/000590.html
* They also complicate ZEO setup, you either need to ensure users end up on the same zope client (with pound or similar) or mount the temporary storage over ZEO (slow).
I'm -0 on including SessionCrumbler and -10 on enabling it by default.
If you want to stop passwords being sent across the ether unnecessarily then the mod_auth_tkt approach is probably better, using cryptographic hashing based on a secret known only to the server. Implementing that scheme for PAS should be fairly simple (there is already some python code to construct cookies)
If you want security you really should encrypt logged in sessions over SSL.
Laurence
plone.session
Posted by
Laurence Rowe
at
February 27, 2007 - 16:33
It seems that sometimes you can have your cake and eat it:
(pasted from plone-dev)
It is already being used for the OpenID authentication support. Using it
for the normal authentication needs should be a trivial change.
Wichert.
Previously Laurence Rowe wrote:
> > +1 if using plone.session. Is that what is currently proposed?
> >
> > Laurence
> >
> > Wichert Akkerman wrote:
>> > > Previously Laurence Rowe wrote:
>>> > >> OK, trying to clear things up a little:
>>> > >>
>>> > >> * Presently the username:password is bas64 encoded as the __ac cookie
>>> > >>
>>> > >> * "Cookies are either stored in memory (session cookies) or placed on
>>> > >> your hard disk (persistent cookies)." http://support.microsoft.com/kb/260971
>>> > >>
>>> > >> * This is a session cookie
>>> > >>
>>> > >> * Any browser that writes a session cookie to disk must be brain dead.
>>> > >> (excepting memory being swapped out of course, but that would be like
>>> > >> finding a needle in a haystack, and if the hacker can do that they could
>>> > >> probably install a keylogger)
>> > >
>> > > And yet it happens.
>> > >
>>> > >> * Sessions are not used in Plone out of the box.
>> > >
>> > > Not yet, Plone 3.0 has all the basic plumbing in place to do that, and
>> > > we might start doing that for the beta.
>> > >
>>> > >> * Zope sessions are "notoriously heavy" (alecm) -
>>> > >> http://lists.plone.org/pipermail/framework-team/2006-September/000590.html
>> > >
>> > > The session authentication implementation in Plone 3 does not use Zope
>> > > sessions.
>> > >
>>> > >> * They also complicate ZEO setup, you either need to ensure users end
>>> > >> up on the same zope client (with pound or similar) or mount the
>>> > >> temporary storage over ZEO (slow).
>> > >
>> > > which means it also does not suffer from this problem.
>> > >
>>> > >> If you want to stop passwords being sent across the ether unnecessarily
>>> > >> then the mod_auth_tkt approach is probably better, using cryptographic
>>> > >> hashing based on a secret known only to the server. Implementing that
>>> > >> scheme for PAS should be fairly simple (there is already some python
>>> > >> code to construct cookies)
>> > >
>> > > And in fact that is exactly what plone.session does.
>> > >
>> > > Wichert.
>> > >
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Plone-developers mailing list
> > Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/plone-developers
-- Wichert Akkerman <wichert-5HFq4VzZ2RFeoWH0uzbU5w@public.gmane.org> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
(pasted from plone-dev)
It is already being used for the OpenID authentication support. Using it
for the normal authentication needs should be a trivial change.
Wichert.
Previously Laurence Rowe wrote:
> > +1 if using plone.session. Is that what is currently proposed?
> >
> > Laurence
> >
> > Wichert Akkerman wrote:
>> > > Previously Laurence Rowe wrote:
>>> > >> OK, trying to clear things up a little:
>>> > >>
>>> > >> * Presently the username:password is bas64 encoded as the __ac cookie
>>> > >>
>>> > >> * "Cookies are either stored in memory (session cookies) or placed on
>>> > >> your hard disk (persistent cookies)." http://support.microsoft.com/kb/260971
>>> > >>
>>> > >> * This is a session cookie
>>> > >>
>>> > >> * Any browser that writes a session cookie to disk must be brain dead.
>>> > >> (excepting memory being swapped out of course, but that would be like
>>> > >> finding a needle in a haystack, and if the hacker can do that they could
>>> > >> probably install a keylogger)
>> > >
>> > > And yet it happens.
>> > >
>>> > >> * Sessions are not used in Plone out of the box.
>> > >
>> > > Not yet, Plone 3.0 has all the basic plumbing in place to do that, and
>> > > we might start doing that for the beta.
>> > >
>>> > >> * Zope sessions are "notoriously heavy" (alecm) -
>>> > >> http://lists.plone.org/pipermail/framework-team/2006-September/000590.html
>> > >
>> > > The session authentication implementation in Plone 3 does not use Zope
>> > > sessions.
>> > >
>>> > >> * They also complicate ZEO setup, you either need to ensure users end
>>> > >> up on the same zope client (with pound or similar) or mount the
>>> > >> temporary storage over ZEO (slow).
>> > >
>> > > which means it also does not suffer from this problem.
>> > >
>>> > >> If you want to stop passwords being sent across the ether unnecessarily
>>> > >> then the mod_auth_tkt approach is probably better, using cryptographic
>>> > >> hashing based on a secret known only to the server. Implementing that
>>> > >> scheme for PAS should be fairly simple (there is already some python
>>> > >> code to construct cookies)
>> > >
>> > > And in fact that is exactly what plone.session does.
>> > >
>> > > Wichert.
>> > >
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Plone-developers mailing list
> > Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/plone-developers
-- Wichert Akkerman <wichert-5HFq4VzZ2RFeoWH0uzbU5w@public.gmane.org> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Scalability
Please notice: Sessions in the standard setup only allow 1k Users simultaneously. After that the transient container will barf. This adds memory overhead on the server side and ZEO problems.