RE: [Zope] CoreSessionTracking-based LoginMethod for LoginManager
- The CST documentation mainly talk about CST as a way of tracking anonymous sessions, but I see no reason why it couldn't be used in this way too...?
Well... one reason is that there is no failsafe access control on session data objects (the token key is the only thing required to grab hold of a session data object and all of its contents via DTML).
Nuts - hadn't thought of that.
As a result, the data that is stored in a session data object would itself need to be encrypted in some way for it to be "secured". Encrypting it assumes some sort of shared key, so you're back to the original problem with a layer of indirection. :-(
OK... So how about the LoginMethod has the key as a property, defined when it's created (heck, even chosen at random and never visible to any user). Then the raw data from the SessionDataManager is useless, 'cos only the LoginMethod knows the key, but the LoginMethod can decode it and decide if they're logged in or not - right? Or am I missing something - is this still insecure?
Safe authentication is a hard problem. The sessioning machinery might help in some way, but it's not an answer in and of itself.
*nods* - I think I'd still like to use it, because it's a nice way to organise things. Putting any meaningful data on the client side gives me heebie-jeebies. Of course, I'm assuming that CST includes checks to guard against cookie-hijacking. :-) -Andy -- Andy Gimblett - Programmer - Frontier Internet Services Limited Tel: 029 20 820 044 Fax: 029 20 820 035 http://www.frontier.net.uk/ Statements made are at all times subject to Frontier's Terms and Conditions of Business, which are available upon request.
Andy Gimblett wrote:
- The CST documentation mainly talk about CST as a way of tracking anonymous sessions, but I see no reason why it couldn't be used in this way too...?
Well... one reason is that there is no failsafe access control on session data objects (the token key is the only thing required to grab hold of a session data object and all of its contents via DTML).
Nuts - hadn't thought of that.
As a result, the data that is stored in a session data object would itself need to be encrypted in some way for it to be "secured". Encrypting it assumes some sort of shared key, so you're back to the original problem with a layer of indirection. :-(
OK... So how about the LoginMethod has the key as a property, defined when it's created (heck, even chosen at random and never visible to any user). Then the raw data from the SessionDataManager is useless, 'cos only the LoginMethod knows the key, but the LoginMethod can decode it and decide if they're logged in or not - right?
That works.
Or am I missing something - is this still insecure?
It's as secure as the key shared by the login method and the object in the session data.
Safe authentication is a hard problem. The sessioning machinery might help in some way, but it's not an answer in and of itself.
*nods* - I think I'd still like to use it, because it's a nice way to organise things. Putting any meaningful data on the client side gives me heebie-jeebies.
Yeah, although it's really the same thing in this case. Encrypting the user info with a shared key and storing it in a cookie isn't really all that much less secure that storing the user info in a session data object. Although I guess it could be argued that in practice, it's more secure, because folks need to know how to ask the session data object for the encrypted user info.
Of course, I'm assuming that CST includes checks to guard against cookie-hijacking. :-)
Um... maybe. What kind of checks did you have in mind? ;-) -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com """ Killing hundreds of birds with thousands of stones """
OK... So how about the LoginMethod has the key as a property, defined when it's created (heck, even chosen at random and never visible to any user). Then the raw data from the SessionDataManager is useless, 'cos only the LoginMethod knows the key, but the LoginMethod can decode it and decide if they're logged in or not - right?
Or am I missing something - is this still insecure?
How about that (just trying to get into that - I always assumed that CookieCrumbler is rather secure, but it seems it could do better): When you log in, the login method authenticates you and then creates a token for you and sends it as a cookie. That token must be hard to guess (i.e. it should not just be the current time or so, but rather random). The more random it is, the more secure it is. From then on, until you log out or the session expires, your token logs you in. The login method just has to keep a dictionary of user/token pairs and expire these tokens as soon as they are no longer valid (you actually wouldn't even have to expire the cookie ...). If I didn't miss something, the only way of hacking left would be a man-in-the-middle attack. But that one could be done much more efficiently by catching your password at logon. To get rid of that problem, use SSL and check the server certificates. I don't see a better solution. It would be nice if one could use SSL for the login only, but how would you prevent the man-in-the-middle thing? Joachim
If I didn't miss something, the only way of hacking left would be a man-in-the-middle attack. But that one could be done much more efficiently by catching your password at logon. To get rid of that problem, use SSL and check the server certificates. I don't see a better solution. It would be nice if one could use SSL for the login only, but how would you prevent the man-in-the-middle thing?
If you cannot rely on IP-adress checking, there is no good way IMHO. A "less worse" way could be to send a new random token to store as a cookie (even possibly with a new cookie-id) with each and every request. That way at least you can do damage control. As soon as the cookie id and or value is unexpected, throw warnings, and kill the users session. /dario - -------------------------------------------------------------------- Dario Lopez-Kästen Systems Developer Chalmers Univ. of Technology dario@ita.chalmers.se ICQ will yield no hits IT Systems & Services
participants (4)
-
Andy Gimblett -
Chris McDonough -
Dario Lopez-Kästen -
Joachim Werner