Improving OpenID's use of cryptography 3 - odds and ends

[Paul Crowley]

Martin Atkins wrote:
>> OpenID consumers and servers should run NTP.  If a timestamp appears 
>> to be in the future, it probably makes sense to tolerate it so long as 
>> the discrepancy is no more than a few seconds.  (This should have gone 
>> into "lifespans" - sorry!)
> 
> That's something that will be impossible for many consumers. Remember 
> that there are loads of weblogs running on crummy hosting accounts where 
> the user only gets FTP access. The user is at the mercy of the server 
> admin to keep the clock set right. While I'd assume that most of them 
> are right, it would be wrong to make this a requirement as there may be 
> a drift of up to five minutes if the clock hasn't been set for a while.

Good point.  Hmm.  The best way to handle this robustly is probably to 
get the server to state the current time when you get its authentication 
key, and calculate and store the server offset.

>> You should make it explicit that the return URL should always contain 
>> a nonce, and should be checked.
> 
> Make it a "best practice", sure, but making it mandatory to send 
> one is just going to give a false sense of security.

By mandatory I just mean mark it a MUST in the spec - I'm not suggesting 
the ID server should attempt to check that the consumer has done so, 
which as you say would be quite impractical.

> I think it's important to bear in mind that many (or even most) 
> consumers aren't going to be big sites like LiveJournal, they are going 
> to be little sites running simple CGI or PHP scripts as part of some 
> simple forum or weblog application they are running. I've not yet 
> absorbed the full implications of your proposals in previous threads, 
> but I think it's important to keep the consumer light. Ideally, I'd like 
> to keep the server light too, but since there will be less of those it 
> doesn't matter so much if they are more complex.

I think my proposals overall make the consumer easier to implement in 
those restricted environments - in particular, you're much more likely 
to have access to HMAC-SHA1 than a DSA verifier.

If you really want to get stateless, with sufficient cunning you could 
use encryption and cookies to store all your state as cookies on the 
client's browser and avoid the need for any server-side storage at all, 
apart from for the encryption secret...

> If it's a pain to implement in a simple and ideally stateless script, 
> it'll only be implemented by the "big guys", and in that case I would 
> consider it a failure just like every other similar scheme before it.

I think it's more important that the API to the script be simple than 
that the internals be so - so long as the script is easy to deploy and 
use, a little extra internal complexity won't hurt them.   In any case, 
the only part of my proposal that's not really essential for security is 
the change to HMAC-SHA1, and that's a simplification that will encourage 
adoption.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/