[OpenID] Using OpenID to store encrypted data

[Breno de Medeiros]

On Wed, Dec 3, 2008 at 12:59 PM, Ennts Ennts
<michael.ennts at googlemail.com> wrote:
> 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.

Note that the spec calls for using the claimed id to identify the
user. If you do not do so for your users, then you may find out that
the user's email address has changed, and they cannot login to your
system. Users can change their email addresses, in particular if they
open a Google account with a non-gmail address and then obtain a Gmail
account.

On the other hand, if you use the claimed_id to identify the user,
Google will provide the new email address to you automatically (if you
are using AX and with user consent). You can safely associate multiple
email addresses to the same claimed_id.

Also, you can't consider something that is sent as an URL parameter as
a secret. It can leak in referrer headers, browser histories. I think
you should not consider claimed_id secrets in a cryptographic sense.

>
>
>> 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
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)