Hi Shade,<br>Thanks for your answer. Please see my comments below<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div class="Ih2E3d"><br>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.<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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)<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.</blockquote>
<div><br>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?<br><br>Best,<br>Michael<br></div>
</div><br>