Dealing with renames

[Kristopher Tate]

On 2005/05/30, at 2:07 PM, Mark Smith wrote:

> I profess early my ignorance of many of the nuances of security.
>
> However, does this matter?

Yes.

> The problem is that the server is
> authenticating someone,

Remember this...

> but if the user changes (as in the case on LJ when
> someone renames their account to a previous account that might have 
> been
> used at some consumer), right?  So, two different people are 
> identified to
> own the same URL.

Correct.

> One of the design goals of OpenID is that you're simply proving "does 
> the
> person with this browser at this moment control this URL."

Ah, but that is merely one.

>
> Putting in any sort of state information, while useful, is not going to
> fix the underlying problem.  If someone gains control over a URL (and
> presumeably the server) then they can pass through any sort of unique 
> ID

This is not the case at all. The UniqueID would be included in the DSS1 
signature. Unless the security was very lax, it is currently impossible 
to forge. The Unique ID would not take the place of the ID-URL, but 
instead be passed along as an argument back to the consumer among 
success.

> and verify anything.  (Of course, assuming they know what hash was 
> being
> used originally, which I can't imagine would be hard to find out if 
> you've
> managed to take over someone's URL.)
>
> Anyway, my point is that I don't think this will fix the problem 
> entirely,
> but should instead be an optional addition that helps to improve 
> security.
>
> If it's kept at that level -- so the consumers aren't required to store
> state information, which might overly complicate some uses of the 
> protocol
> -- then I think it's a good idea and would like to lend my support.

Awesome.

 From what I've seen by example and by what I'm currently doing with 
OpenID, it would be more than fair to say that OpenID may be used 
primarily in two ways.

The first is to assert that the individual in question has control of 
all subsequent information on a sub-domain, or sub directory. This is 
good because we can ascertain that everything on the sub-domain or 
sub-dir tree is safe to parse as that identity's.

The second, as shown on the OpenID wiki 
<http://www.lifewiki.net/openid/>, OpenID-URLs can be used to identify 
someone, in-order to gain access or post other information. This also 
applies to blogs as well.

The first has already been supplemented well, many of us have working 
code. The second works too, but there is a problem. The problem is 
that, as you yourself mentioned above, if someone changes their name or 
someone else takes it, the consumer still contains info on that person!

Two (or more) bad things can happen as a result:

1) Someone obtains the exact ID-URL, and gains access to information 
that isn't theirs.
2) The person who originally had that URL has to go around and either 
close accounts, delete information, etc... AND THEN RE-ENTER it. I 
don't like re-entering information... especially passwords everywhere 
-- that's why I invented Level9 -- and presumably why you guys invented 
OpenID, as well.

With a uniqueID, a user can be any URL on the FQDN, and still login to 
each of the other sites. This has an added benefit when 
user.livejournal.com decides that he wants to use 
livejournal.com/~user/ one day, and it'll still work.

The Consumer can take the info out of that asserted ID-URL, just like 
it normally would -- but the user would still have the same 
credentials.

This also has an added benefit: profiles.

Say mylevel9.com/user/testaccount has two hidden profiles. Work and 
Play.

What if mylevel9.com/user/testaccount wants to login to an OpenID 
consumer, but because it's a friend's Guestbook, he wants to login 
under play -- it has more info about him, afterall.

So, he enters mylevel9.com/user/testaccount/play -- because the server 
gets a uniqueid back from the server -- if sometime later, the same 
testaccount user enters in mylevel9.com/user/testaccount the server 
will still know who he is, and won't ask him to enter the same info and 
the like...

I hope this answers things...

More anon,

-Kristopher Tate