Re: Cosign Re-Authentication Specification

[Cory Snavely <csnavely@xxxxxxxxx>]

Nicely done, folks, as usual. I have a suggestion and a thought and a 
suggestion:

* Suggestion. On the re-auth page, it occurs to me that if someone
  *innocently* arrives there, they are unlikely to suffer through n
  attempts at impersonation without knowing that afterward they get
  to authenticate as themselves. The way it is currently kind of
  assumes they are up to no good.

  I think there should be a "this isn't me--log on as a different
  person" button. Not quite sure how to word that, but I think it's
  needed to help the innocent victim.

* I agree with the others that the *service* sometimes needs to have
  weblogin force reauthen. I definitely can think of instances where
  the service might want to decide to reauth--for example, for a
  particularly sensitive operation, as you see on e.g. buy.com or
  travelocity before you complete a transaction.

  To do that securely, though, the application must somehow communicate
  that need to the local cosign module or weblogin. I think this is
  trickier than it sounds to do in such a way that the user can't
  easily defeat. The two secure approaches I can think of require
  state.

  So, I would propose that service-side forcing of authen--IOW, forcing
  authen *after* a service cookie exists--be considered a case of the
  "authen timeout" feature that has been discussed before. I would
  conceive this as Apache directives that specify pairs of regexps and
  time thresholds that the local cosign module enforces by ignoring the
  service cookie if the age of authen falls outside the allowable
  parameters. Set it to 15 seconds for a regexp that matches your VISA
  card entry page URL; set it to 10 minutes for a regexp that matches
  the whole financial module of your application.

  So, a distinctly different feature, and not combined with this
  proposed reauth change for whole services that always require
  reauthen for entry.

Thanks,
Cory

Brian Hatch wrote:
> > this is very cool, and is some the University of Auckland would be very
> > interested in also. One thing which might be nice (but is a larger
> > impact) is the ability for the filter to tell the cosign server to
> > reauthenticate (i.e. passing a reauth tag to the CGI, no registration
> > etc). This means the filter might then be able to force the user to
> > reauthenticate perhaps every 10 minutes to continue to access the
> > financial system etc? What do you think? Also the advantage of this is
> > it leads to forcing reauth for certain URLs in the application, like for
> > example in the finacials, to change the pay rate or something like that.
> > Thoughts?
>
>
> The one big worry with any kind of 'more frequent authentication' system
> is you probably want to disable the re-auth for POSTs, since that data
> is lost in the redirects.  On a POST heavy site, this could mean you
> evade reauthenticating for a while, but I'd hate to be filling out my
> billpay and lose it after I'd authenticated 10 minutes ago.  GET re-auth
> only, or configurable in httpd.conf.