[security] PAPE Policy for RPs to force authentication without browser cookie

[Allen Tom]

Hi Andrew -

At least in the case of Yahoo, and presumably with other webmail 
providers and social networks, disclosing when the user signed in can be 
a privacy issue.

Users currently have the expectation that they can sign into their 
webmail provider silently, without telling everyone that they're signed 
in. In the case of Yahoo (and I believe is also the case with all the 
other OPs), we issue long lived authentication cookies, so a user who 
signed into their OP with the expectation that the login event was 
"silent" now can have that event exposed. I think this is only realy an 
issue if the login event was relatively distant in the past.

A real world example is that a user can claim to have been offline 
during a certain time, however the user silently signed into their OP to 
check mail, without signing out. A couple days later, the user then uses 
their OpenID, and the fact that the user signed in at a certain time 
(when the user claimed to be offline) will be disclosed to the RP.


Allen




Andrew Arnott wrote:
> Allen,
>
> Is it really that bad of a privacy problem for the RP to learn how 
> long ago the user signed in?  Most OPs leave persistent cookies on the 
> browser, so my OP might say I logged in 3 seconds ago or 3 weeks ago.  
> Of what use is that to an RP except to determine whether they can 
> trust the OP's assertion about my identity, and how might that 
> adversely affect me?
>
> I'm probably missing something simple.  Any explanation will be helpful. 
>
> Thanks.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the 
> death your right to say it." - S. G. Tallentyre
>
>
> On Tue, Jun 30, 2009 at 9:23 PM, Allen Tom <atom at yahoo-inc.com 
> <mailto:atom at yahoo-inc.com>> wrote:
>
>     Many websites require users who are already authenticated to
>     re-verify their password before entering a sensitive area.
>
>     For instance, retailers like Amazon allow users to browse their
>     website in a recognized state, but will verify the user's password
>     in order to place an order. Similarly, Facebook requires logged in
>     users to re-verify their password in order to manage their credit
>     cards, and Yahoo and Google have similar password verification
>     requirements in order to enter sensitive flows.
>
>     The PAPE Extension seems to be the right way to implement this
>     functionality in OpenID, and I believe that the authors of the
>     PAPE spec intended RPs to be able to specify
>     openid.pape.max_auth_age=0 in the request to ask the OP to
>     authenticate the user without relying on browser cookies. In the
>     case where the user is already authenticated at the OP (using
>     cookies), the expectation is that the OP re-authenticates the user
>     before returning a positive assertion to the RP. In the most
>     common case, where the user authenticates with a password, the OP
>     is expected to verify the user's password before returning the
>     assertion to the RP.
>
>     Although this sounds fairly straightforward, there are some
>     non-obvious edge cases that should probably be clarified.
>
>     For instance, what if the RP specified max_auth_age=<1 minute>?
>     Sometimes users take a few minutes to complete the OpenID sign in
>     flow (they might get distracted), and although the user may have
>     entered their password immediately after being redirected to the
>     OP, the user may have taken more than a minute to navigate through
>     the OP's approval screen, before clicking on the button to return
>     back to the RP.
>
>     Another case is where the RP specified max_auth_age=999999999999.
>     The PAPE spec requires the OP to respond back with the the time
>     the user last authenticated, if the max_auth_age is greater than
>     the duration of the user's current session with the OP. This
>     effectively gives the RP a way to find out when the user last
>     signed in, which potentially violates the user's privacy.  Many
>     users expect to be able to sign into their OP silently, and to be
>     able to use services at their OP without anyone besides their OP
>     knowing that they were online.  Obviously, using OpenID to signin
>     to an RP exposes to the RP that the user is online at the moment
>     of authentication, however it's probably a very bad idea for the
>     OP to return when the user signed into the OP if the sign-in event
>     was more than (X hours?) in the past.
>
>     In order to provide a standard "force authentication" interface, I
>     propose that either we define a new PAPE policy, or we clearly
>     define max_auth_age=0 as a special value.
>
>     The "force authentication" policy must require OPs to
>     re-authenticate the user after the user is redirected to the OP
>     and before returning the assertion to the RP. In the case where
>     the user is authenticated with a password, the OP is required to
>     re-verify the user's password. If the OP displays additional
>     screens to the user after verifying the user's password, the OP
>     must ensure that the user's IP address did not change after the
>     password was verified and the assertion returned.  OPs should be
>     able to support this policy without also supporting other non-zero
>     values for max_auth_age.
>
>     comments?
>     Allen
>
>
>
>
>
>
>     _______________________________________________
>     security mailing list
>     security at openid.net <mailto:security at openid.net>
>     http://openid.net/mailman/listinfo/security
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20090702/f5d27c23/attachment.htm>