On Thu, 03 Aug 2006 12:17:03 +0200, Manlio Perillo <manlio_perillo@libero.it> wrote:
I'm interested in this. Are there any examples?
I would like to add a section on authorization, too.
The avatar object is exactly that kind of example. It contains all the needed information to authorize it at application level through some locateChild level mechanism. There are many examples of that in stiq.
Line 19: The most secure way is to use HTTPS, based on SSL. But SSL can cause too burden on an application.
The most secure way to do what?
To use sessions.
I think you are confused here... HTTPS and sessions are 2 totally different things.
Line 82: * when an user want to change the email and you send the forgotten password via email, ask for the password.
This is just senseless. I forgot the password and I want it back. To have it back I should insert it? Didn't I forget it?
No, you misunderstand what I have written ;-).
It's not very clear.
The system should ask for the user password when the user wants to change its email address. This is important *if* the system allow an user to ask for its forgotten password and this is sent to its email address.
An attacker (that obtained a valid session ID) can change the account email address and ask for the password!
This is a non-problem with my guard. Asking authentication each time invalidates the current session credentials (because you changed the password in the database when you autogenerated a new one). To reach the user pages again you'd have to know the autogenerated one. because the one stored in the session is not valid anymore.
Session section: Why is it suggested to use cookies when at the end of the same subsection you say that this approach has several flaws?
Because, by design, sessions are not good for authentication.
sessions are not authentication, of course they are not good for that.
However cookies based sessions are better that URL based sessions or form based sessions.
They are different kind of things. Sometimes clients don't support cookies. How are you going to provide a usable website for them?
The only flaw of a well written session management system (as I can understand) is a replication attack (done by someone that can see the traffic beetwen client and server).
Just use HTTPS.
This assuming that one isn't using permanent sessions.
There is no such thing as permanent sessions. They might be persistent for some time but not permanent.
A persistent cookie for a day or so can be used when a simple login is done. Transient cookies and session for anonymous sessions.
Line 41x: This looks WAAAAAAY too paranoid for the real risks. Just use HTTPS is you are so scared of people stealing other's passwords.
No, because HTTPS **is not** needed to keep user's password safe. It is only need for the login page.
Much of the problems you are trying to find here are all resolved by using https for everything in your website. I doubt it's worth to lose so much developer time in trying to make secure something that cannot be secure by design (there is a machine that is not under your control and that is also the one you want to protect). Just use HTTPS for all your website. Safer and simpler.
No. I can create a complete "static" site, with all Resources created at start time.
You can do _EXACTLY_ the same thing with guard. Did I mention that guard is like it is to avoid changing ANY code in your application?
Maybe I need to add some examples. And I would like to do some benchmark to understand the cost of creating every resource object on the fly.
rend.Page() objects are made to be destroyed for every request. And this will be enforced without the context. Also... Are you actually worrying about creating one object compared to the cost of rendering a dynamic page? (and locating it!) Of course there's nothing that prevents you to return always the same page object from guard.
And guard has some (avoidable) security problems, too... It uses URLs based sessions without my permission.
my who? user? developer?
Here I'm really curious. Is cred + guard really so reusable?
yes.
As an example, how easy it is to write an integrated authentication code (as an example on Windows's Active Directory)?
IIRC Active Directory is pretty much LDAP. Which means that it's almost a no-brainer.
The session handling code can be factored out in a Mixin class. This mixin only have to check for a session and, if available, to set the username attribute on the request object (or None, if no session exists).
Requires changing the application code which might not react as expected to the mixin.
This allow one to write custom code, as an example one can create an additional cookie with a signed and crypted client address, using the same interface.
Or, more paranoic, one can create an additional cookie with a signed and maybe encrypted serial number. This number is incremented at every request (both on the session cookie and on the session object) and checked.
This looks so paranoid I can't believe anyone could use it... Why should I need such a secure way of communicating through the web? there are already other kinds of mechanism that are even more secure than that. I think HTTPS, secure cookies and encrypted cookie values are more than enough to barely trust a cookie. Anyway it seems reasonable to factor out the cookie handling stuff.