[security] OpenID Security Best Practices Doc

[Nate Klingenstein]

Allen,

Inline as well:

> [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.

True.  I think the session cookie recommendation for RP's along with a  
discussion for users and RP's of the implications of a persistent  
cookie at the OP would be a nice medium.

> [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.

This is intended to be best practices rather than common practices,  
though, isn't it?  Though I certainly agree we can't be prescriptive,  
we can make very strong recommendations and make clear what the  
exposure is from not using https.

Even if you can't get the RP or OP to use https, there are still  
significant protective benefits from doing it on either leg of the  
transaction.

>> 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.

Agreed.  I wouldn't completely remove the mention there, but I  
strongly believe we should generalize the point in a separate section  
as well.  Even if there isn't much to write now, with reputation  
services, XRDS, third party validation, etc. on the way, it will get  
fleshed out in time.

>> 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.

Gulp.

This is a really interesting problem that we don't encounter in  
deployments on our scale -- still large, but not so large that  
replication can't be done.  It argues strongly for both the use of  
HTTPS and short assertion lifetimes.  We've been surprised how many  
deployers have issues dealing with clock synch, but that's probably a  
lesser evil than serious replay.

> 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.

Probably.  But if it's not HTTPS, and the nonce can't be checked, the  
threat surface from replay is huge.  Compromised clients could pose  
the same issue.

I think it's quite appropriate to make a recommendation for expires_in  
in this document.  But I'm not convinced that such an automated attack  
that results in a long-lived session is really mitigated by a narrow  
timeframe.

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

Yes, you've got the common specific attack vectors pretty thoroughly  
covered already.  I'm just referring to explanatory text of the issues  
surronding persisting non-secure session cookies after session  
establishment, and again the replay risks of sending a bearer  
assertion over plain http.  This would fit naturally with the  
discussion of the use of session cookies by the RP.

Spooked by the difficulty of replicating the nonce,
Nate.