I was wondering if my solution to the problem outlined below would be a useful inclusion into the main CMF code tree?
I solved this by encrypting the __ac_name and __ac_password values in the URL and then hacked CookieCrumbler.py to decrypt them before it sets the cookie.
The general idea is that the user would setup the path to a method called decrypt as a property of the cookie crumbler. If this property is non NULL the cookie crumbler calls it to decrypt the values b4 setting the cookie, in an instance where the value is not decrypted the decryption mechanism should return the value passed to it.
--On Donnerstag, 23. Dezember 2004 11:47 Uhr -0800 Declan Shanaghy declan@shanaghy.com wrote:
I have set up a portal of shopping sites. Each merchant we support has their own domain set
up.
e.g.
Seeing as they are shopping sites certain pages have to be handled by SSL.
Due to SSL limitations only 1 SSL domain+certificate can exist per ip, and we only have 1 ip. Therefore
my
solution is that for non SSL pages the merchant can use their own unique domain name, but all SSL pages will be redirected to
https://merchantname.portal.com and an SSL
certificate
is setup with a CN of *.portal.com
A problem arises when switching between domains like this. The login cookie is lost. Curently i do a redirect between domains and include __ac_name and __ac_password arguments in the URL so the user stays logged in, but this causes the username and password to be displayed in the address bar in plain text.
I'd like to secure this more.
Is there any way that i could
A - Encrypt __ac_name and __ac_password values?
or
B - Set the cookie for both domains so name and password dont have to be transferred?
Declan Shanaghy wrote:
I was wondering if my solution to the problem outlined below would be a useful inclusion into the main CMF code tree?
Well, CookieCrumbler *should* be on a downhill path anyway, with PluggableAuthService (PAS) coming strong now, so I would suggest that moving to PAS would be a better idea.
That said, CookieCrumbler currently is about the least secure authentication method that it is possible to devise. ;) The only unsecure thing it doesn't do is store it on disk, since the cookies are set to expire when you close the browser.
CookieCrumbler, as well as standard Basic HTTP Authentication, sends the username and password, unencrypted, with every request. This is obviously not a very good idea. This is open for a whole host of possible ways of figuring out your username and password.
The easiest way to solve that is to let the cookie be only a random ticked. That way the userame and password is only sent when actually logging in. This gives as much security as your solution, but it's easier to implement. PluggableUserFolder does, and I think PAS does it do (or at least it will do that soon). This means that it will be a bit harder to figure out your username and password. You'll need to intercept the login request. You still can intercept ANY request and then use this to hijack the authentication ticket and subsequently use your logged in account, so it is still not much security to talk about. It is an easy enough improvement to do, so it should be done, but it given no significant extra security.
Cookie hijacking is possible to prevent by only allowing one ticket to come from one IP-address. Unfortunately, doing that will also make it practically impossible to login from most dial-up (including ADSL) connections. I have suggested that an option for binding sessions to IP-adresses should be added to the session handler, so that it can be enabled for intranets for example. But for most sites it's not a practical solution. And you can still get the username and password by tapping into your login requests.
The next step up in security after that is the largest, most difficult, but also most effective step: Using SSL. By slapping an Apache server in front of the webserver, or using one of the native Zope SSL products, you can get encrypted communications between the client and the server. You can then NOT find the username and password, and you can NOT hijack the cookies, buceuase you can't intercept and decrypt the submitted data. Problem solved.
So, in short: If you want some extra security: Use PAS. If you want real security, use SSL.
The easiest way to solve that is to let the cookie be only a random ticked. That way the userame and password is only sent when actually logging in. This gives as much security as your solution, but it's easier to implement. PluggableUserFolder does, and I think PAS does it do (or at least it will do that soon).
PAS can do it currently by e.g. combining a CookieAuthHelper with a SessionAuthHelper. The CookieAuthHelper only intercepts the initial login page and gets the credentials (it does not set a cookie), and only the SessionAuthHelper is called as a CredentialsUpdater - the credentials thus end up in the session and the standard sessioning cookie is the "random ticket".
jens
---------------
Jens Vagelpohl jens@zetwork.com Software Engineer +49-(0)441-36 18 14 38 Zetwork GmbH http://www.zetwork.com/
-
Declan Shanaghy -
Jens Vagelpohl -
Lennart Regebro