Question about Zope and security
Hi there, I have been telling all my clients about how great Zope is for security: fine-grained permissions, security framework, roles, etc. Now, one of my clients has a security expert who took a close look at how Zope authenticates users. The results were not good. The main problem is that Zope stores the username and password in a cookie in clear text (base64 encoded). Even though it only happens in their internal network, my client wasn't too happy, because it makes them vulnerable to a man-in-the-middle attack. I know, the odds of that happening are low, but storing the username and password in clear text is clearly not best practice. So, my question is: is there a way to secure Zope authentication? I did find Dieter Mauer's DigestAuth product: http://www.dieter.handshake.de/pyprojects/zope/#DigestAuth It looks good. I have used other produts from Dieter before and was very pleased with the quality of his code. Now, have other people used it? Does it work with WebDAV? How secure is it (I am no security/encryption expert)? Also, if it is good, why is not part of default Zope?? Finally, a little side story: you know how in Windows XP, you can connect a drive to a WebDAV server? Well, if you install Service Pack 2, you can't use that feature to connect to Zope anymore. Interestingly enough, it seems that it is precisely because of that authentication vlunerability: Win XP SP2 refuses to connect to a WebDAV that doesn't at least encode the username/password in Digest authentication... Any comment or pointers are very welcome. Cyrille
Cyrille Bonnet wrote:
The main problem is that Zope stores the username and password in a cookie in clear text (base64 encoded).
Even though it only happens in their internal network, my client wasn't too happy, because it makes them vulnerable to a man-in-the-middle attack.
I know, the odds of that happening are low, but storing the username and password in clear text is clearly not best practice.
So, my question is: is there a way to secure Zope authentication?
Stock Zope doesn't use cookie authentication, so you're actually talking about an alternate user folder product (which you don't specify and I don't know that many of them, so I can't really comment much -- except that SimpleUserFolder with CookieCrumbler will indeed put you in this situation (or did the last time I checked)). The fact that Zope stores passwords as plain text is not the issue if you're worried about man-in-the-middle attacks, though. The problem there is that you are passing passwords plain text in the request, and there is almost no way around that unless you run an SSL (HTTPS) server. Which you should if you want real security. Encrypting your password database without moving your server login to HTTPS is only going to create inconvenience without improved security (you can no longer send password reminders, for example) -- it's a false sense of security. So, IMHO, secure the server, then worry about password databases. Cheers, Terry
Hi Terry, thanks for your comment.
Stock Zope doesn't use cookie authentication, so you're actually talking about an alternate user folder product (which you don't specify and I don't know that many of them, so I can't really comment much -- except that SimpleUserFolder with CookieCrumbler will indeed put you in this situation (or did the last time I checked)).
I am using Plone 2.1.2, which uses CookieCrumbler. I wanted to put the problem in a Zope perspective, though: this is why I didn't mention that.
The fact that Zope stores passwords as plain text is not the issue if you're worried about man-in-the-middle attacks, though. The problem there is that you are passing passwords plain text in the request, and there is almost no way around that unless you run an SSL (HTTPS) server. Which you should if you want real security.
Sorry, I wasn't even aware that Zope stores the passwords in plain text. My primary concern (for the moment) is passwords in plain text in the request. I had thought of SSL, but it doesn't solve the problem for WebDAV access. I should also mention that the site is for the general public, with a few users logging in. Of course, I can't put the public site on SSL, so I would have to have a separate URL for logged-in users with SSL. And I still have to worry about the ZMI and WebDAV access. It seems so much simpler to solve the problem at the root: change Zope authentication.
Encrypting your password database without moving your server login to HTTPS is only going to create inconvenience without improved security (you can no longer send password reminders, for example) -- it's a false sense of security.
Ouch, so on top of my concerns, passwords are stored in plain text?? Thanks for pointing that out. I'd rather encrypt passwords with a hash and reset the password if the users have lost it. Is it possible to do that in Zope? Obviously, I don't understand the ins and outs of Zope as well as most people on this list. So, my questions really are: * why is Zope authentication implemented that way? * Is it really complex to secure the authentication process? * Is there any documentation summing up Zope security (authentication process, password storage, etc.)? Cheers, Cyrille
Cyrille Bonnet wrote:
Hi Terry,
thanks for your comment.
Stock Zope doesn't use cookie authentication, so you're actually talking about an alternate user folder product (which you don't specify and I don't know that many of them, so I can't really comment much -- except that SimpleUserFolder with CookieCrumbler will indeed put you in this situation (or did the last time I checked)).
I am using Plone 2.1.2, which uses CookieCrumbler. I wanted to put the problem in a Zope perspective, though: this is why I didn't mention that.
The fact that Zope stores passwords as plain text is not the issue if you're worried about man-in-the-middle attacks, though. The problem there is that you are passing passwords plain text in the request, and there is almost no way around that unless you run an SSL (HTTPS) server. Which you should if you want real security.
Sorry, I wasn't even aware that Zope stores the passwords in plain text. My primary concern (for the moment) is passwords in plain text in the request.
I had thought of SSL, but it doesn't solve the problem for WebDAV access.
I should also mention that the site is for the general public, with a few users logging in.
Of course, I can't put the public site on SSL, so I would have to have a separate URL for logged-in users with SSL. And I still have to worry about the ZMI and WebDAV access.
It seems so much simpler to solve the problem at the root: change Zope authentication.
Encrypting your password database without moving your server login to HTTPS is only going to create inconvenience without improved security (you can no longer send password reminders, for example) -- it's a false sense of security.
Ouch, so on top of my concerns, passwords are stored in plain text?? Thanks for pointing that out.
I'd rather encrypt passwords with a hash and reset the password if the users have lost it. Is it possible to do that in Zope?
Obviously, I don't understand the ins and outs of Zope as well as most people on this list. So, my questions really are:
* why is Zope authentication implemented that way? * Is it really complex to secure the authentication process? * Is there any documentation summing up Zope security (authentication process, password storage, etc.)?
Cheers,
Cyrille
___
Cyrille, I am curious: If HTTPS is a hassle, then what do your security experts have as a secure alternative? All best, David
I'd rather encrypt passwords with a hash and reset the password if the users have lost it. Is it possible to do that in Zope?
Isn't there an option in GRUF to encrypt passwords? Although I don't think that affects the user's sending of passwords over the Web. Peace, George
Cyrille Bonnet wrote:
Hi Terry, ... Sorry, I wasn't even aware that Zope stores the passwords in plain text. My primary concern (for the moment) is passwords in plain text in the request.
No it does not. The default userfolder stores passwords hashed. Regards Tino
Tino Wildenhain wrote:
Cyrille Bonnet wrote:
Hi Terry, ... Sorry, I wasn't even aware that Zope stores the passwords in plain text. My primary concern (for the moment) is passwords in plain text in the request.
No it does not. The default userfolder stores passwords hashed.
What userfolder are you referring to? Both Zope's default user folder and cookie crumbler both store the password base64 encoded, not hashed, there's a big difference. That said, it's a config option per user folder as to whether or not password are stored encrypted in the ZODB. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers schrieb:
Tino Wildenhain wrote:
Cyrille Bonnet wrote:
Hi Terry,
...
Sorry, I wasn't even aware that Zope stores the passwords in plain text. My primary concern (for the moment) is passwords in plain text in the request.
No it does not. The default userfolder stores passwords hashed.
What userfolder are you referring to?
Both Zope's default user folder and cookie crumbler both store the password base64 encoded, not hashed, there's a big difference.
Well, not that cookie crumbler stores any passwords anyway .-) The checkbox is there for a long time. I might have read about that its default now or just hallucinated ;) ++Tino
Cyrille Bonnet wrote:
I am using Plone 2.1.2, which uses CookieCrumbler. I wanted to put the problem in a Zope perspective, though: this is why I didn't mention that.
Then I'd suggest going and bugging the Plohn people about this. CookeCrumbler _is_ insecure, and I've pointed this out and provided convoluted patches in the past. But even with those patches, you _still_ need to use https to get real security ;-)
I had thought of SSL, but it doesn't solve the problem for WebDAV access.
Huh? WebDAV over SSL will work just fine...
I should also mention that the site is for the general public, with a few users logging in.
So have the users who need to log in use a different subdomain, and make sure that's all SSL encrypted.
Of course, I can't put the public site on SSL,
Why not? If you're _so_ fussed about security, that's what you _need_ to do...
It seems so much simpler to solve the problem at the root: change Zope authentication.
Great, patches accepted. But please bear in mind we will rip them to shreds, especially if they use cookies or don't use SSL...
I'd rather encrypt passwords with a hash and reset the password if the users have lost it. Is it possible to do that in Zope?
You can do anything you want, you just have to write the code.
* why is Zope authentication implemented that way?
what way? http basic auth is a standard. cookie auth isn't, and it's always insecure no matter how you implement it
* Is it really complex to secure the authentication process?
Yes. Always. Get over it. You _will_ screw it up so stop getting you knickers in a twist...
* Is there any documentation summing up Zope security (authentication process, password storage, etc.)?
Probably. Why don't you have a look? Failing that, there's always the source code... Seriously, you're worrying about stuff you shouldn't. If you really care about security, unplug your server put it in a safe and leave it there. And pay someone to guard it and make sure no-one even sets eyes on it, let alone powers it up. If you're moderately concerned about security, https _all_ your website interactions. Use client-side certificates to authenticate over SSL. Rigorously train all your users about security. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers schrieb: ...
what way? http basic auth is a standard. cookie auth isn't, and it's always insecure no matter how you implement it
they are both equally insecure - while you can make the cookie (as session auth) a little more secure - but after all its worth nothing as long as you dont transfer the credentials initially encrypted :-) ++Tino
Cyrille Bonnet wrote:
Hi there,
I have been telling all my clients about how great Zope is for security: fine-grained permissions, security framework, roles, etc.
Now, one of my clients has a security expert who took a close look at how Zope authenticates users. The results were not good.
The main problem is that Zope stores the username and password in a cookie in clear text (base64 encoded).
No, zope does not do that. There are userfolders and extensions (like cookie crumbler) which do that. You can have any mechanism you want.
Even though it only happens in their internal network, my client wasn't too happy, because it makes them vulnerable to a man-in-the-middle attack.
So does it? With ssl layer?
I know, the odds of that happening are low, but storing the username and password in clear text is clearly not best practice.
Sure you have to take care - but enabling some kind of digest auth (below) isnt that hard - otoh, your password will be transfered over the net in clear text in many cases - if you have a form based login you will for sure transfer clear text username and password. You could try javascript tricks to put digest like authentication in a form based login, but thats not so easy and bullet proof. And if you stress it too much you have great security - but no users :-) So if you are security concerned, just put an ssl-layer on top of zope. Usually via apache mod_ssl, mod_proxy and mod_rewrite. You can also use pound or squid.
So, my question is: is there a way to secure Zope authentication?
I did find Dieter Mauer's DigestAuth product: http://www.dieter.handshake.de/pyprojects/zope/#DigestAuth
Digest out - so your users browser support it, is a solution and better then basic-auth. However you dont have a nice login form and you cant logout.
It looks good. I have used other produts from Dieter before and was very pleased with the quality of his code.
Now, have other people used it? Does it work with WebDAV? How secure is it (I am no security/encryption expert)?
WebDAV is just HTTP, so all you apply to it holds true for WebDAV as well - beside the fact you cant have login forms. So basic auth or digest auth can be used and can be secured via ssl.
Also, if it is good, why is not part of default Zope??
Cookie auth isnt part of default zope either.
Finally, a little side story: you know how in Windows XP, you can connect a drive to a WebDAV server? Well, if you install Service Pack 2, you can't use that feature to connect to Zope anymore. Interestingly enough, it seems that it is precisely because of that authentication vlunerability: Win XP SP2 refuses to connect to a WebDAV that doesn't at least encode the username/password in Digest authentication...
Yes, MS never gets it right with official standards. You can patch around to make it work with the windows of the day, but you might need to change it next time again. However you can use 3rd party products like WebDrive/TeamDrive which have been reported to work flawlessy since the early days of zopes webdav support. Kind regards Tino
On 3/30/06, Cyrille Bonnet <cyrille@3months.com> wrote:
The main problem is that Zope stores the username and password in a cookie in clear text (base64 encoded).
As mentioned before, Zope doesn't, but CookieCrumbler (and hence Plone) does. And, the security expert is not much of a security expert at all, if he doesn't know this: You will only get real web security with SSL.
Even though it only happens in their internal network, my client wasn't too happy, because it makes them vulnerable to a man-in-the-middle attack.
All plain http is vulnerable to that, which is why If you care about security, you need to use https.
So, my question is: is there a way to secure Zope authentication?
Yup. See above. :)
Also, if it is good, why is not part of default Zope??
Good question. :-) However, today you want to use PAS. The new fancy modular user folder for Zope. I don't know if it works with Plone yet, though. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Cyrille Bonnet wrote:
Hi there,
I have been telling all my clients about how great Zope is for security: fine-grained permissions, security framework, roles, etc.
Now, one of my clients has a security expert who took a close look at how Zope authenticates users. The results were not good.
The main problem is that Zope stores the username and password in a cookie in clear text (base64 encoded).
*Zope* don't do that. It's the (infamous) CookieCrumbler products that is responsible for this horror.
Even though it only happens in their internal network, my client wasn't too happy, because it makes them vulnerable to a man-in-the-middle attack.
I know, the odds of that happening are low, but storing the username and password in clear text is clearly not best practice.
That's an understatement.
So, my question is: is there a way to secure Zope authentication?
yes : use https. -- bruno desthuilliers développeur bruno@modulix.org http://www.modulix.com
+-------[ bruno desthuilliers ]---------------------- | Cyrille Bonnet wrote: | > Hi there, | > | > I have been telling all my clients about how great Zope is for security: | > fine-grained permissions, security framework, roles, etc. | > | > Now, one of my clients has a security expert who took a close look at | > how Zope authenticates users. The results were not good. | > | > The main problem is that Zope stores the username and password in a | > cookie in clear text (base64 encoded). | | *Zope* don't do that. It's the (infamous) CookieCrumbler products that | is responsible for this horror. Lots of UserFolders do this by default for compatibility reasons. CookieCrumbler is just following a long tradition. It's EXACTLY the same as what you get with Basic Auth. exUserFolder has a mode uses a random hash for cookies (I'm sure other UserFolders have this option as well). But as others have said, if you're posting to a form and not using https, what's the point. -- Andrew Milton akm@theinternet.com.au
Thanks to all for your feedback: I understand better what is going on now. SSL is definitely the way to go, that would solve all my problems. Now, just to push the problem a bit further: ideally, I'd like to put SSL just on the login form. Zope would authenticate the user in that request and return a "session ID" that would then be passed back and forth in each request (without SSL). That would be a balanced approach to security: I don't have to put SSL across the entire site. The site will be vulnerable to man-in-the-middle attacks, but only for the duration of a session. Is it possible to do that with Zope? Or does Zope require to identify the user on each request? Thanks for the help. Cyrille bruno desthuilliers wrote:
Cyrille Bonnet wrote:
Hi there,
I have been telling all my clients about how great Zope is for security: fine-grained permissions, security framework, roles, etc.
Now, one of my clients has a security expert who took a close look at how Zope authenticates users. The results were not good.
The main problem is that Zope stores the username and password in a cookie in clear text (base64 encoded).
*Zope* don't do that. It's the (infamous) CookieCrumbler products that is responsible for this horror.
Even though it only happens in their internal network, my client wasn't too happy, because it makes them vulnerable to a man-in-the-middle attack.
I know, the odds of that happening are low, but storing the username and password in clear text is clearly not best practice.
That's an understatement.
So, my question is: is there a way to secure Zope authentication?
yes : use https.
On Fri, Mar 31, 2006, Cyrille Bonnet wrote:
Thanks to all for your feedback: I understand better what is going on now.
SSL is definitely the way to go, that would solve all my problems.
Now, just to push the problem a bit further: ideally, I'd like to put SSL just on the login form. Zope would authenticate the user in that request and return a "session ID" that would then be passed back and forth in each request (without SSL).
That would be a balanced approach to security: I don't have to put SSL across the entire site. The site will be vulnerable to man-in-the-middle attacks, but only for the duration of a session.
I've done this using custom skins, copying the login_form and modifying it to use https when submitting. Bill -- INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 There are three kinds of men. The ones that learn by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves. -- Will Rogers
On 3/30/06, Cyrille Bonnet <cyrille@3months.com> wrote:
Now, just to push the problem a bit further: ideally, I'd like to put SSL just on the login form. Zope would authenticate the user in that request and return a "session ID" that would then be passed back and forth in each request (without SSL).
I'd recommend the Yale CAS system. It does exactly this. I wrote a plugin for PAS for it, and I think I have some Cookie.Crumbler type thingy somewhere too.
Cyrille Bonnet wrote at 2006-3-30 14:43 +1200:
... I did find Dieter Mauer's DigestAuth product: http://www.dieter.handshake.de/pyprojects/zope/#DigestAuth
It looks good. I have used other produts from Dieter before and was very pleased with the quality of his code.
Now, have other people used it? Does it work with WebDAV?
It should work with WebDAV, provided the WebDAV client supports HTTP Digest Authentication.
How secure is it (I am no security/encryption expert)?
The corresponding RFC (RFC 2617) explains in detail how secure the basic mechanism is. My "DigestAuth DigestAuthCrumber" adds a bit of insecurity: * the passwords must be stored (inside Zope (!) not in the request) in plain text. This could be improved a bit, either by - using two way encryption -- but Zope must be able to get the plain text password back. - fixing the domain and using storing the "MD5" hash of username, password and domain instead of the plain text password. Other authentication schemes would then need to be changed -- to use the same "MD5" hash.
Also, if it is good, why is not part of default Zope??
There are two sides of an answer: the Zope developpers/maintainers side and my side. Adding even a good package to the core means a (rather) long term commitment to support and maintain this package. When you follow "comp.lang.python" (or the corresponding mailing list), you see how reluctant the Python developpers are to include additional packages into the Python core -- to avoid these responsibilities. The Zope maintainers are even stricter: they look what they can get rid of rather than what they can include.... On my side: developping for the Zope core imposes much more overhead than developping independently: I would have to make a proposal, follow (partially stupid) style guides, add more tests (than necessary to convince me that the quality is sufficient)... Thus, I am reluctant to develop for the Zope core. -- Dieter
Hi Dieter, thanks for your response. It helps a lot. It looks like DigestAuth is a step in the right direction, but needs more work to be completely secure. I'll get back to my client and see where they want to go from here. Thx for your help. Cheers, Cyrille Dieter Maurer wrote:
Cyrille Bonnet wrote at 2006-3-30 14:43 +1200:
... I did find Dieter Mauer's DigestAuth product: http://www.dieter.handshake.de/pyprojects/zope/#DigestAuth
It looks good. I have used other produts from Dieter before and was very pleased with the quality of his code.
Now, have other people used it? Does it work with WebDAV?
It should work with WebDAV, provided the WebDAV client supports HTTP Digest Authentication.
How secure is it (I am no security/encryption expert)?
The corresponding RFC (RFC 2617) explains in detail how secure the basic mechanism is.
My "DigestAuth DigestAuthCrumber" adds a bit of insecurity:
* the passwords must be stored (inside Zope (!) not in the request) in plain text.
This could be improved a bit, either by
- using two way encryption -- but Zope must be able to get the plain text password back.
- fixing the domain and using storing the "MD5" hash of username, password and domain instead of the plain text password.
Other authentication schemes would then need to be changed -- to use the same "MD5" hash.
Also, if it is good, why is not part of default Zope??
There are two sides of an answer: the Zope developpers/maintainers side and my side.
Adding even a good package to the core means a (rather) long term commitment to support and maintain this package. When you follow "comp.lang.python" (or the corresponding mailing list), you see how reluctant the Python developpers are to include additional packages into the Python core -- to avoid these responsibilities. The Zope maintainers are even stricter: they look what they can get rid of rather than what they can include....
On my side: developping for the Zope core imposes much more overhead than developping independently: I would have to make a proposal, follow (partially stupid) style guides, add more tests (than necessary to convince me that the quality is sufficient)... Thus, I am reluctant to develop for the Zope core.
participants (11)
-
Andrew Milton -
Bill Campbell -
bruno desthuilliers -
Chris Withers -
Cyrille Bonnet -
David H -
Dieter Maurer -
George Lee -
Lennart Regebro -
Terry Hancock -
Tino Wildenhain