Dealing with renames

[Mark Smith]

I profess early my ignorance of many of the nuances of security.

However, does this matter?  The problem is that the server is
authenticating someone, 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.

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

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

-jr

On Mon, May 30, 2005, Ben Hyde wrote:
> I think the assertion returned by the ID server needs to change.
> 
> Let's say that we have the open ID  martha.example.com, it's owned 
> first by Alice, and then later by Zeno.  Assume that the same ID 
> server, Victor, is involved in both time periods.  Assume that the same 
> client server, Sam, asks about it in both time periods.
> 
> Currently the assertion that Victor provides to Sam is identical 
> (excepting the time stamp) even though Victor knows that Alice isn't 
> Zeno.
> 
> That is bogus.
> 
> The fix is easy, but it requires adding something to the assertion.
> 
> Have Victor add something that changes when the owner changes.
> 
> The added field is based on Victor's knowledge of Alice (or Zeno).   
> But it should reveal almost nothing about them to Sam.  So it might be 
> something like SHA1("Sam", "Alice", "victor_private_salt").   This 
> value is an opaque identifier for Alice that can only be dereferenced 
> back to Alice by Victor.  Call this the opaque_id.
> 
> Meanwhile the spec needs to be clear that assertions from two different 
> ID servers (i.e. Victor-1 and Victor-2) about the
> same ID are entirely independent.   ID clients of the assertions are 
> careful about that, and pay attention to the opaque id they get back, 
> then they can avoid assuming that Alice is Zeno.
> 
>   - ben
> 
> _______________________________________________
> yadis mailing list
> yadis at lists.danga.com
> http://lists.danga.com/mailman/listinfo/yadis


--
Mark Smith
junior at danga.com