[OpenID] Using OpenID to store encrypted data

[Ennts Ennts]

Hi Shade,
Thanks for your answer. Please see my comments below

>
>  I have a web application which uses OpenID to identify my users. For each
>> user I'd like to store some encrypted data that only the user should be able
>> to retrieve. For that I need a key which is _not_ stored in my application.
>>
>
> I have considered this problem previously. The trick is that, if *you* need
> the key at all, you're decrypting the data on your end before sending it to
> the user - and then all an attacker has to do is break into your machine,
> install some spyware, and wait for the user to log in (or, imitate the
> user). If you know what encryption key to use for a given user, you also
> know what their OpenID (the obvious "secret" string) will be, and in
> watching for this you also have the string to watch for contained in your
> code! You might be able to add some obscurity to this by looking for a hash
> rather than the exact string itself, but also consider how easy it could be
> for attackers to discover the OpenID's of people you associate with (that
> might be using your site) or to search for your site using Google to
> discover who has mentioned it (and therefore might be a user of it). Also,
> access logs *may* reveal OpenID request strings (since they pass some OpenID
> arguments as part of the URL), which would reveal URI's to anyone breaking
> in.
>

Of course, this cannot work. The thing that led me to ideas was Google's
Federated Login: the response from Google include (1) the user's email, and
(2) the OpenID URL, which is unrelated to the email and unique for a given
realm. OK, I don't know if the realm can be faked (?), but if not, this
would allow me to store the user's email as their unique identifier, and use
the OpenID url as a key, as only my host can obtain that, and only after a
successful user login. I guess this is kind of in contradiction to OpenID's
intended use, and it would not work for general OpenIDs where claimed_id is
in general totally public and an email may not be present, or if it is,
easily linked to an OpenID.


 I think that ultimately what I'd like is that the OpenID provider returns a
> response consisting of the claimed_id (used as a user identifier in my
> application) together with a piece of data (acting as a key)
>

So the OP, which normally has the power to pose as your user, will now be
> able to dictate their key as well? Sounds to me like you may as well go with
> HTTPS for transmission of the sensitive data and forget about a second layer
> of encryption, since the OP will be able to compromise the user's privacy
> effortlessly if you do it that way.


Yes, if the OP can tell if a user is logged into my system, I can't see why
he shouldn't also be able to dictate keys used in my app? Or perhaps I
misunderstand your point?

Best,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081203/b56112e8/attachment-0002.htm>