[security] OpenID Security Best Practices Doc

[Allen Tom]

Hi Nate,

Thanks for the feedback, my comments are inline.

Nate Klingenstein wrote:
>
> 1)  Might mention in the logout section for users that closing a 
> browser will also (generally, thanks Firefox) terminate session cookies.
[atom] This makes sense if RPs and OPs always use session cookies that 
are cleared with the browser is closed for their authentication 
credentials, however, I don't know if RPs and OPs generally do this. 
Recommending that RPs only use session cookies sounds like a good idea.

Many OPs give users the option (sometimes enabled by default) to set 
permanent authentication cookies that persist long after the user's 
browser and computer are shutdown and restarted, so telling users that 
closing their browser will log them out would be inaccurate in many cases.

> 2)  I think authentication session duration is very 
> deployment-specific and it would be difficult to make any general 
> recommendations.
[atom] Agreed. I was hoping that we could give a recommendation to RPs  
for the authentication session lifetime, as well as the frequency to 
call checkid_immediate, but perhaps this is too deployment-specific.

>
> 3)  I don't think the discussion of the benefits of https for user 
> authentication to the OP is given enough emphasis.  It would be nice 
> to state clearly the protection against MITM, promiscuous listeners, 
> etc. that https provides, so that OP's realize exactly what protection 
> TLS/SSL offers.
[atom] Using HTTPS for the entire end-to-end protocol flow sounds like a 
really good thing. Many RPs that care a lot about security are requring 
that OPs use HTTPS for everything, however, recommending that HTTPS be 
used for everything also implies that the OpenID URL itself should be 
HTTPS, and there are many OpenIDs in the wild (for instance, blog 
owners, etc) that don't use HTTPS.

> 4)  I'd disentangle the wording about RP/OP trust from the specific 
> point about PAPE.  Provider trust is a more general topic that is 
> really important, and I think it merits its own section.  I'm happy to 
> draft that if you'd like.
[atom] One of the reasons why I wanted to include trust in the PAPE 
discussion is that just because an OP supports PAPE does not imply that 
the OP can be trusted to actually implement PAPE in a manner consistent 
with the RP's expectations.

> 5)  For account linking, I'd clarify the text that so the need to 
> authenticate the user separately from the assertion is explicit.
[atom] Good point.

> 6)  Pull the replay warning into its own bullet, and mention the use 
> of a timestamp to bound the time nonces must be stored for.
[atom] Also a good point. On a related note, many large globally 
distributed RPs may have a hard time implementing nonces as per the 
OpenID spec, as it's technically tricky to globally replicate data, 
especially if it needs to be replicated very quickly. In practice, RPs 
may only find it practical to verify that the timestamp is "current" as 
opposed to actually verifying that the nonce is can only be used once.

If the entire protocol is implemented over HTTPS, including the RP's 
return_to URL, then verifying that the timestamp without verifying that 
rest of the nonce unique is probably sufficient.

> 7)  Is it worth mentioning more generally anything about session or 
> assertion hijacking and possible countermeasures?
>
[atom] Are you referring to XSS/XSRF/clickjacking?

Thanks for the feedback!
Allen