Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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 won't. Well, they will. You go from being able to sniff from ANY request, to only being able to sniff from the login request. Session ID re-use will only work if the legitimately logged in user doesn't use the session they've just logged in to. If they do, both the legitimate and illegitimate session will get bumped out. Now, dependent on your point of view and the sensitivity of your data, that may only be a small improvement, but it IS an improvement... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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 Plone users they will be safer with a session token, because they won't. Why not make the login page itself SSL-protected then? If you're going to go to the trouble of setting up SSL, why not encrypt the whole session? Let anonymous users come in via HTTP, then go all-SSL for logged in users. Sourceforge is a great example of this. Yes, thats what I was talking about. In our Zope apps this is standard procedure -- we have one non-SSL welcome page at the most, everything else goes through HTTPS, makes sense IMHO for data acquisition applications with at least moderately sensitive data peter. smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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'll give Chris Withers the maintainer hat. He'll start with your latest version. I'll certainly take that on, if only because Cookie Crumbler is in such wide use. 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 ;-) That said, basic auth ain't much better, but at least that's protectable by SSL... Cookies and Basic Auth both are transmitted via HTTP headers, so both should benefit from SSL Another question of course is what happens afterwards; in my experience at least IE has a tendency to even store Session cookies longer than one might expect (ie. the lifetime of the browser instance) I made a patch to CC to crypt auth tokens with AES, though thats not ideal it should help a little Hmmm, I wonder about sticking the token in the URL as an option, as with the SESSION stuff... Chris smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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 > > users they will be safer with a session token, because they won't. > > Why not make the login page itself SSL-protected then? If you're going to go to the trouble of setting up SSL, why not encrypt the whole session? Let anonymous users come in via HTTP, then go all-SSL for logged in users. Sourceforge is a great example of this. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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 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 won't. Shane Why not make the login page itself SSL-protected then? peter. smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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 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 won't. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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 Withers the maintainer hat. He'll start with your latest version. I'll certainly take that on, if only because Cookie Crumbler is in such wide use. 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 ;-) That said, basic auth ain't much better, but at least that's protectable by SSL... Hmmm, I wonder about sticking the token in the URL as an option, as with the SESSION stuff... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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 do, but I'll happily give you the > > chance to prove me wrong. :-) > > I wouldn't be taking it in any direction - I like the product the way > it is (Now I have checked in my code :-) ). Give me a poke if you don't > feel like applying bug fixes though. 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 Withers the maintainer hat. He'll start with your latest version. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
-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 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 do, but I'll happily give you the chance to prove me wrong. :-) I wouldn't be taking it in any direction - I like the product the way it is (Now I have checked in my code :-) ). Give me a poke if you don't feel like applying bug fixes though. - -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAgLQXAfqZj7rGN0oRAtRqAJ92YgRN62v9S/NLKrihGZguNnQF9gCgmyg4 EGTx2vtEJ7EKLlFjMEBWe8s= =uEZG -END PGP SIGNATURE- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
-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 pretty similar. It looks like it was written against the CMF's Cookie Crumbler rather than the standalone - I don't know if these two implementations have diverged much or not. - -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAgLKtAfqZj7rGN0oRApVJAJ93KDOQZ2qV9v8gDv5adu5ITDu8rgCfa/0R ZRfH3ojpD4qQjx/XQ3B3wrM= =AtNX -END PGP SIGNATURE- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [patch] More secure cookie crumbler?
-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 SQLSession product, instead. No experience unfortunately, although I do use sessions stored in the ZODB rather than temporary storage. I would consider it a bug if it didn't work :-) Performance may be an issue depending on how you use your SESSIONs of course which I suspect would be the major issue with doing this. SessionStorage would work either as a separate product, or as a knob for the CookieCrumbler, I think. If ZPL is an adequate license, why don't you check it in there? I've checked a version into Products/CookieCrumber and added a note to the CHANGES.txt - -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAgK/jAfqZj7rGN0oRAuvLAJ0dc8+B6NuTnIbUQWOV2OqCQYCfJQCeNHJm t6lrGtXwIkmhRr+O9VPrHuQ= =f7dh -END PGP SIGNATURE- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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 Zope's user folders. See the middle of > this page for a fairly clear explanation: > > http://frontier.userland.com/stories/storyReader$2159 The problem with that is that as far as I know, it still doesn't offer a nice, clean, cross-browser way of logging out. Which means most people will still use cookie-authentication... ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [patch] More secure cookie crumbler?
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 client user is not permitted to write HTML content to be stored by the app? The malicious code doesn't have to be stored in the app being attacked. Typically its part of a URI pointing to the app to attack and includes the xss payload. That URI however could be found any number of places... social engineering usually comes into play then to get the victim to click on it. While its typically easier to convince users to click a link if it comes from the same site it appears to be going to, (think about message board systems like slash where where hyperlinks in comments are usually suffixed by [domain.com] to give the user the ability to avoid goatse and such) in the end, what dictates the likelyhood of attack is the value of the service more than anything. [Sadly this doesn't dictate the likely hood of XSS holes getting reported on security lists, where people frequently post every about silly little backwater application they can find.] Yup. I worry hard about XSS when it comes to my banking, my credit cards, my taxes; I don't much care when it comes to a news site. restrictions, etc. but few people will go through the trouble, and I'd wager most people using the various cookie-based auth folder products don't even know the risks. This I'd agree with, but I find the argument "this car's breaks only let me stop in 1 mile, so there's no point in changing them so I can stop in 0.5 miles" a poor one... Well, knock yourself out, I mean, clearly auth techniques based around cookies need a lot of additional protection. Those same protections, if written modularly, can usually be used to bolster HTTP auth as well, so there's no harm in writing them. Its convincing people to actually use the damned things thats the problem. Right, mostly for the same reasons you point out above: the perceived threat isn't enough to warrant the pain. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation "Zope Dealers" http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [patch] More secure cookie crumbler?
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 tokens in a module global. Do not apply it. I've attached some similar code we are using. Instead of patching CookieCrumbler, it extends it and is drop-in compatible. We are stuffing the auth credentials into the SESSION, so it will work with ZEO if your SESSION machinery copes (either using server affinity or your session storage is mounted by the ZEO clients from a central storage). I was going to pack this up and release it as a product under BSD or MIT licence, but I either forgot or came up with a technical reason not to. Either way, I'm having memory issues :-) Does this look worth releasing as a separate product? 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 SQLSession product, instead. SessionStorage would work either as a separate product, or as a knob for the CookieCrumbler, I think. If ZPL is an adequate license, why don't you check it in there? PS: To make cookie auth properly secure, you really need to be working over SSL only I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler. Unfortunately it causes performance to blow. We compromise by having the auth form on the SSL server, but the rest of the application on raw HTTP. This at least reduces the window that a replay attack can be used. It would be possible to tie the auth credential down to a particular IP address, but that is entering the world of diminishing returns and incompatibilities (think ISP's with farms of proxies - is this still a problem nowadays?). Yes; not only that, but AOL users change their IPs seemingly at random during a single session. Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation "Zope Dealers" http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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 it any direction you want. I don't believe its model can support well the things you're asking it to do, but I'll happily give you the chance to prove me wrong. :-) Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
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. Do not apply it. I've attached some similar code we are using. Instead of patching CookieCrumbler, it extends it and is drop-in compatible. We are stuffing the auth credentials into the SESSION, so it will work with ZEO if your SESSION machinery copes (either using server affinity or your session storage is mounted by the ZEO clients from a central storage). I was going to pack this up and release it as a product under BSD or MIT licence, but I either forgot or came up with a technical reason not to. Either way, I'm having memory issues :-) SessionCookieCrumbler.py Description: Binary data Does this look worth releasing as a separate product? PS: To make cookie auth properly secure, you really need to be working over SSL only I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler. Unfortunately it causes performance to blow. We compromise by having the auth form on the SSL server, but the rest of the application on raw HTTP. This at least reduces the window that a replay attack can be used. It would be possible to tie the auth credential down to a particular IP address, but that is entering the world of diminishing returns and incompatibilities (think ISP's with farms of proxies - is this still a problem nowadays?). -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/ PGP.sig Description: This is a digitally signed message part ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [patch] More secure cookie crumbler?
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 to go in this direction at all. A much more fruitful endeavor would be to simply add digest authentication support to Zope's user folders. See the middle of this page for a fairly clear explanation: http://frontier.userland.com/stories/storyReader$2159 Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [patch] More secure cookie crumbler?
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 only work on setups where there's at most one ZEO client accepting web requests for each user. However, all you have to do is drop 3 ZSQL-methods-filtereted-through-python-scripts or python-scripts-using-a-session-data-container and it works across any number of ZEO clients accepting web requests for any user. PS: To make cookie auth properly secure, you really need to be working over SSL only I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler. That was the reason for the long NB/PS at the end of the email. The patch does still prevent the Browser seeing the password of the user, and reduces the chances of session hijacking. With normal cookie crumbler, if you snoop a session, you can keep using it until the user changes their password. With the patch, at longest it'll be until the app server is restarted, but more likely the 20 minute session expirey time on the server and, if the session was being using actively at the time it was snooped, until the user next requests a page. 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 ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [patch] More secure cookie crumbler?
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 properly secure, you really need to be working > over SSL only I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
