Shane Hathaway wrote:
Even with unbreakable encryption of credentials after login, you still
send the username and password in the clear at login time, and sniffers
can reuse the session ID with ease. You really shouldn't tell the Plone
users they will be safer with a session token, because they
Shane Hathaway wrote:
On Tue, 20 Apr 2004, Peter Sabaini wrote:
Shane Hathaway wrote:
Even with unbreakable encryption of credentials after login, you still
send the username and password in the clear at login time, and sniffers
can reuse the session ID with ease. You really shouldn't tell the
Chris Withers wrote:
Shane Hathaway wrote:
Hmm. I really wasn't expecting any new code yet. Session cookies are a
very significant maintenance burden in Zope, and it's not in my interest
to support them. If you don't mind, I think I'll release a version of CC
without any session support, then I
On Tue, 20 Apr 2004, Peter Sabaini wrote:
> Shane Hathaway wrote:
> > Even with unbreakable encryption of credentials after login, you still
> > send the username and password in the clear at login time, and sniffers
> > can reuse the session ID with ease. You really shouldn't tell the Plone
> >
Shane Hathaway wrote:
On Tue, 20 Apr 2004, Chris Withers wrote:
I wonder how many Plone users are aware their passwords are stored
unencrypted in client cookies which fly back and forth waiting to be
snapped up by packet sniffers, XSS, and JS attacks ;-)
Even with unbreakable encryption of cred
On Tue, 20 Apr 2004, Chris Withers wrote:
> I wonder how many Plone users are aware their passwords are stored
> unencrypted in client cookies which fly back and forth waiting to be
> snapped up by packet sniffers, XSS, and JS attacks ;-)
Even with unbreakable encryption of credentials after logi
Shane Hathaway wrote:
Hmm. I really wasn't expecting any new code yet. Session cookies are a
very significant maintenance burden in Zope, and it's not in my interest
to support them. If you don't mind, I think I'll release a version of CC
without any session support, then I'll give Chris Wither
Shane Hathaway wrote:
Making cookie authentication secure is surprisingly difficult, and you've
barely taken one step.
So how does PAS do cookie auth then?
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
On Sat, 17 Apr 2004, Stuart Bishop wrote:
> > BTW, I wouldn't mind if you or Stuart took over maintainership of
> > CookieCrumbler after the next release. Then you'd be able to take it
> > any direction you want. I don't believe its model can support well
> > the things you're asking it to d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/2004, at 1:40 PM, Shane Hathaway wrote:
On 04/12/04 09:04, Chris Withers wrote:
For me, that's worth patching for, it's up to you if you want to
include it in an offical CookieCrumbler release or not ;-)
BTW, I wouldn't mind if you or Stuart
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/2004, at 4:28 PM, Kapil Thangavelu wrote:
fwiw, Simon Eisenmann checked in a SessionStorage product into the
collective which does much the same. released under the zpl
http://cvs.sourceforge.net/viewcvs.py/collective/SessionCrumbler/
Looks pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/2004, at 3:34 PM, Tres Seaver wrote:
I haven't looked at the code. Do you have actual experience using
core sessions over ZEO? I pondered that recently for a client, and
fell back to using a hacked together version of Anthony Baxter's
SQL
From: "Shane Hathaway" <[EMAIL PROTECTED]>
> Making cookie authentication secure is surprisingly difficult, and you've
> barely taken one step. I don't want CookieCrumbler to go in this
> direction at all. A much more fruitful endeavor would be to simply add
> digest authentication support to Zop
fwiw, Simon Eisenmann checked in a SessionStorage product into the
collective which does much the same. released under the zpl
http://cvs.sourceforge.net/viewcvs.py/collective/SessionCrumbler/
-kapil
___
Zope-Dev maillist - [EMAIL PROTECTED]
http:/
Jamie Heilman wrote:
Chris Withers wrote:
The patch means that auth creds are never sent, only an auth token that's
valid for 20 mins or so, or you could set it to less.
The token *is* the cred in that scenario, you can't not send some form
credentials.
Can you explain the XSS risk when a cl
Stuart Bishop wrote:
On 12/04/2004, at 10:39 PM, Shane Hathaway wrote:
On Mon, 12 Apr 2004, Chris Withers wrote:
I think the attached patch (against CookieCrumbler 1.1) makes
CookieCrumbler a little more secure.
Your patch won't work with multiple ZEO app servers. It appears to store
the token
On 04/12/04 09:04, Chris Withers wrote:
For me, that's worth patching for, it's up to you if you want to include
it in an offical CookieCrumbler release or not ;-)
BTW, I wouldn't mind if you or Stuart took over maintainership of
CookieCrumbler after the next release. Then you'd be able to take
On 12/04/2004, at 10:39 PM, Shane Hathaway wrote:
On Mon, 12 Apr 2004, Chris Withers wrote:
I think the attached patch (against CookieCrumbler 1.1) makes
CookieCrumbler a little more secure.
Your patch won't work with multiple ZEO app servers. It appears to
store
the tokens in a module global.
On Mon, 12 Apr 2004, Chris Withers wrote:
> For me, that's worth patching for, it's up to you if you want to include
> it in an offical CookieCrumbler release or not ;-)
Making cookie authentication secure is surprisingly difficult, and you've
barely taken one step. I don't want CookieCrumbler t
Shane Hathaway wrote:
I think the attached patch (against CookieCrumbler 1.1) makes
CookieCrumbler a little more secure.
Your patch won't work with multiple ZEO app servers. It appears to store
the tokens in a module global. Do not apply it.
Well, that's a little harsh. The default methods will
On Mon, 12 Apr 2004, Chris Withers wrote:
> I think the attached patch (against CookieCrumbler 1.1) makes
> CookieCrumbler a little more secure.
Your patch won't work with multiple ZEO app servers. It appears to store
the tokens in a module global. Do not apply it.
> PS: To make cookie auth pr
21 matches
Mail list logo