Better error messages maybe? :-)

[Michael 'hacker' Krelin]

On Mon, Aug 15, 2005 at 02:33:35PM -0700, Jeremy Smith wrote:
> I see what you're saying.  My original idea was a site where people
> could ONLY log in through OpenID (as in, there are no user accounts
> for this site specifically) and then my site would not have to host
> any sensitive cookie information.  Then users could have their own
> javascript and other so-called "Web 2.0" nifties without being able to
> hijack other people's logins by stealing cookie information.
> 
> Looks like I should have thought it through better :-)

Well, Web is what it is. All you can hope for is that you'll be able to
delegate those 'vulnerabilities' to the other site (your idea was to
delegate it to OpenID server).

Love,
H

> 
> -Jeremy
> 
> On 8/15/05, Michael 'hacker' Krelin <hacker at klever.net> wrote:
> > On Mon, Aug 15, 2005 at 01:46:22PM -0700, Jeremy Smith wrote:
> > > By storing an assertion in the session, doesn't that leave the user
> > > vulnerable to replay attacks via cookie theft?  I was hoping using
> > 
> > As much as having persistent session (login, for instance) at all.
> > OpenID lets user confirm who they are like they would do with mere
> > password otherwise. It's up to you what to do with the user once
> > authenticated - use it, for instance, for adding comment and forget or
> > keep session information for the user (possibly associated with IP
> > address).
> > 
> > Love,
> > H
> > 
> > 
> > > OpenID for decentralized authentication would
> > > quell that problem.
> > >
> > > But now that I think about that, I guess there's no way to do it.  Hmmm.
> > >
> > > -Jeremy
> > >
> > > On 8/15/05, Martin Atkins <mart at degeneration.co.uk> wrote:
> > > > Jeremy Smith wrote:
> > > > >
> > > > > Now, another question: How is an OpenID consumer to deal with staying
> > > > > logged in?  Shall I verify the ID (entailing a series of redirects)
> > > > > for every page request?
> > > > >
> > > >
> > > > You should create a session of some description for your user which has
> > > > a duration of as long as you are willing to trust the assersion. How
> > > > long you are willing to allow is up to you, depending on the sensitivity
> > > > of your application and any other criteria you like. How you track the
> > > > session is entirely up to you as well.
> > > >
> > > > Re-verifying for every request is possible but certainly not a good
> > > > idea. For one thing, users whose ID servers don't have a "Yes, every
> > > > time" option will have to keep authorizing it over and over, and I'm
> > > > sure the identity servers themselves won't be too happy.
> > > >
> > > >
> > >
> >
>