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

[Martin Atkins]

Paul Crowley wrote:
> 
> 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...
> 

I already run a site which uses a trick like that to avoid storing login
session state on the server, but I do it while assuming that it's only
slightly more secure than it would be to just store the user's password
in a cookie. Still, coming from someone who clearly knows a lot more
cryptography than I do I'll take the assersion that this is possible and
secure on trust for now.

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

Certainly, if all the details are hidden inside a consumer library then
I would accept that as simple, as long as the library doesn't have any
crazy dependencies. Ideally such a library would also be able to operate
both in stateful (with an application-supplied external storage
implementation) and stateless (where such an implementation is not
supplied) modes and handle your "sufficient cunning" as noted above.