Dick Hardt wrote:
Well, if the RP is deliberately violating the user's privacy to find
out when the user authenticated at the OP, it could send multiple
checkid_immediate requests, decrementing the max_auth_age value each
time, until it found the real value.
Errr, the RP gets back what it sent each time. I am suggesting
changing the spec for the privacy reasons you stated. The RP does not
need to know when the last auth was, just that it met the RP's policy.
It never learns anything except for seeing how long it is before the
OP returns a result.
Am I missing something?
Oh I see. The PAPE spec says that the OP is supposed to return the time
at which the user had last actively authenticated with the OP. I had
assumed that the RP could try several values, and would be able to find
the correct value when the OP suddenly returns pape.auth_time=<now>
Simply returning the auth_time=max_auth_age is probably a good enough
workaround, although a really evil RP could measure the latency of the
response to try determine what happened on the OP side.
What are you looking for in this use case where the IP address changes?
Sites that force the password to be re-verified before entering a
sensitive flow often require that the user's IP address remain fixed
throughout the flow, or else they'll require the user to
re-authenticate.
why?
The user's machine could get a new, dynamic IP address between HTTP
requests. I don't see that as a security violation. I really don't
understand the security issue here. Please enlighten me!
One possible reason why the user's IP address may appear to have changed
is because an attacker stole the user's browser cookies, and the
attacker (with a different IP address) is now pretending to be the user.
Allen
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
