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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://openid.net/mailman/listinfo/security >> > > >
_______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
