Maximizing cacheing of server secrets
Paul Crowley
paul at ciphergoth.org
Sun Jun 5 08:53:20 PDT 2005
This is just a little extra for my list of odds and ends.
We want to be able to use the same cached server secret to authenticate
more than one user on that server. However, the URLs for those users
are different, so how are we to know that we can re-use these server
secrets?
Consider the "Randy attack":
http://lists.danga.com/pipermail/yadis/2005-May/000025.html
To understand the attack, remember that LiveJournal neither knows nor
cares who really controls bradfitz.com. Any LiveJournal user can tell
LJ that they control bradfitz.com, and LJ will not try and find out if
they're telling the truth. So if the owner of bradfitz.com is to say
which user is allowed to assert identity with that domain, they must say
it in the URL that references livejournal.com as the identity server.
Something like:
<link rel="openid.server"
href="http://www.livejournal.com/auth/?type=openid&user=brad" />
Meanwhile, I'll put something like this on the index page of ciphergoth.org:
<link rel="openid.server"
href="http://www.livejournal.com/auth/?type=openid&user=ciphergoth" />
Now, if ydnar.com has successfully authenticated Brad, it will have an
authentication key from LJ, which they'll associate with the URL
http://www.livejournal.com/auth/?type=openid&user=brad
So when I go to log into the same site, it won't reuse that secret,
it'll fetch another one.
The most straightforward and secure solution I see is to separate out
the function of delegating identification from performing it. Brad and
I put URLs more like this on our web pages:
<link rel="openid.delegate"
href="http://www.livejournal.com/users/ciphergoth" />
and that page contains
<link rel="openid.server"
href="http://www.livejournal.com/auth/?type=openid" />
So when I claim to be ciphergoth.org, ydnar.com will follow the
delegation and ask LiveJournal.com if I'm really
http://www.livejournal.com/users/ciphergoth - a question that
LiveJournal is in a position to answer authoritatively. LiveJournal
will simply refuse to assert any URLs about which it cannot speak
authoritatively. And the openid.server URL will be the same for me as
for Brad, so it can stay in the cache.
If I don't want to give away what LJ user I am to ydnar.com, then as
Brad suggests, I can delegate to a URL like
http://www.livejournal.com/auth/anonuser?id=27349832
I can press a button and ask LJ for an anonymous ID and it'll give me
one like the one above, up to some maximum. All of these URLs lead to a
very short page that just says
The advantage of this over the ljuser_sha1 scheme Brad outlined at one
point is that even if I guess that brad is the true owner of
bradfitz.com (who'da thunk it?) I can't confirm my guess. No changes to
the OpenID protocol are needed for this; it's just a feature LJ can
support if it so chooses.
A final quick point for consideration - should we provide a way for
consumers to know, if the server wishes them to know, that
ciphergoth.livejournal.com and www.livejournal.com/~ciphergoth are one
and the same? This would be done with a third kind of link header,
something like
<link rel="openid.canonical"
href="http://www.livejournal.com/auth?user=ciphergoth" />
--
__
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/
More information about the yadis
mailing list