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

[Andrew Arnott]

Ah, thanks.  Especially the real world example helped me understand the
danger.
--
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 Thu, Jul 2, 2009 at 10:28 AM, Allen Tom <atom at yahoo-inc.com> wrote:

>  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> 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
>> http://openid.net/mailman/listinfo/security
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20090702/ba61d5ed/attachment.htm>