shared secret alternative to DSA

[Paul Crowley]

Nathan D. Bowen wrote:
> I would go so far as to say that the almost-explicit role of OpenID is 
> to protect college girls' blogs from their bitter ex-boyfriends whose 
> fraternity brothers are the sysadmins on their campus networks.

This is a great model of the attacker.  I'm reminded of jwz's assertion 
that the purpose of groupware tools is to help college kids get laid :-)

Here's a more detailed imagining: say the server is LiveJournal, and the 
consumer is a calender app hosted by a friend from the broadband 
connection in their flat.  (I'd say their dorm room, but that network is 
broadband connection is probably switched).  However, it's the bitter ex 
who set up the broadband connection, and he controls the broadband 
router.  He could modify packets as they go by, but that's harder than 
running "ethereal" and he feels a bit more like a cracker doing it, so 
he doesn't.  Instead he sniffs the connection, picks up the MAC secret, 
and forges his way into the calendar app, getting all the information he 
needs to stalk her.

This is the right kind of thinking, but the trouble with this example is 
that it's much easier for him to just sniff her cookie once she's logged 
in, isn't it?  And why does forging IP headers make him feel like a 
cracker, but forging OpenID authentication tokens feels OK?  It's really 
pretty easy for him to set up the routing table so packets intended for 
LJ go to his box - probably easier than writing software to generate 
fake OpenID tokens based on snarfled MAC secrets.

As I say, though, I'm not stuck on this - I am a bit worried about 
whether this is best for the simplest clients, and if I can't bring 
people round, I'll drop it and move on to working out how to do DSA 
properly...
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/