Security Patterns

mrflip edited this page Aug 17, 2010 · 3 revisions

Security from the perspective of a community site.

Better than anything you’ll read below on the subject:

Snazzy Diagram

(in notes/SecurityFramework.png)


  • Identification: “Who are you?” Assign this visitor a name and an associated
    identity (picture, website, favorite pokemon, trust metric, security roles).
    “Behold. I am not Gandalf the Grey, whom you betrayed, I am Gandalf the White,
    who has returned from death.” — Tolkien
  • Authentication: “Prove it.” Verify this visitor matches the claimed identity.
    “My name is Werner Brandis. My voice is my password. Verify me.” — Sneakers
  • Authorization: “You may do A, B & C, but never D, E, or F” — Actions this
    visitor may perfom on a given resource.
    “Of every tree of the garden thou mayest freely eat: But of the tree of the
    knowledge of good and evil, thou shalt not eat of it: for in the day that thou
    eatest thereof thou shalt surely die.” — Gen 2:16-17
  • Trust: “You’ve earned the right to do D and E, but not F” Extent you expect
    this visitor will act reliably.
    “A copper! A copper! How d’ya like that, boys? And we went for it. I went
    for it. Treated him like a kid brother. And I was gonna split fifty-fifty with
    a copper.” — James Cagney, White Heat
    Trustlet Wiki
  • Reputation from Trust Network: Award trust to this visitor based on what other
    trusted parties say.
    “He used my name? In the /street/? He called me a punk? My name was on the
    street? When we bounce from this s—t here, Y’all gonna go down on them
    corners, let the people know: word did not get back to me. Let ’em know Marlo
    step to any m——-f—-: Omar, Barksdale, whoever. My name IS my NAME.” — Marlo
    Stansfield, The Wire (paraphrased)
  • Reputation from Past Actions:
    “The man you just killed was just released from prison. He could’ve f—in’
    walked. All he had to do was say my dad’s name, but he didn’t; he kept his
    f—ing mouth shut. And did his f—in’ time, and he did it like a man. He did
    four years for us. So, Mr. Orange, you’re tellin’ me this very good friend of
    mine, who did four years for my father, who in four years never made a deal,
    no matter what they dangled in front of him, you’re telling me that now, that
    now this man is free, and we’re making good on our commitment to him, he’s
    just gonna decide, out of the f—ing blue, to rip us off?” — Nice Guy Eddie,
    Reservoir Dogs
  • Auditing
  • Recovery


@@ The below is a mixture of half-baked, foolish and incomplete. Just sos you know. @

  • Identity here will mean ‘online presence’ — user account, basically.
  • Person will mean the remote endpoint — whether that’s a person or robot or
    company. (Security papers call this “Subject” but that’s awful).
  • It’s easy to confuse ‘person’ and ‘identity’, so easy I probably have below.

Why do you need to authenticate? For authorization. So traditionally, we think

person <- (ath’n token) <- identity <- (policy) <- actions

That is, actions are attached to an identity by security policy, identity is
attached to a person by their authentication token.

The problem is that we cannot authenticate a /person/, only the token they
present: password, ATM card+PIN number, etc.
“The Doors of Durin, Lord of Moria. Speak friend, and enter” — Tolkien
Anyone who presents that card+PIN, Elvish catchphrase, or voice print will be
authenticated to act as the corresponding identity (account holder, friend of
the elves, nerdy scientist), and we have no control over those tokens.

person <- (ath’n token) <- identity <- (az’n policy) <- actions ^^ This step is wrong.

The solution is to not care, or rather to reframe our goals.

What we actually want is not to /control/ users’ actions, but to /predict/ them.
When Mr. Blonde helps Mr. White rob a jewelry store it’s a security failure for
the store but a success for the crime gang. When Mr. Orange (an undercover cop)
shoots Mr. Blonde it’s a security failure for the crime gang and a success for
the police. We want to know how to use

( identity, past actions ) => (trust, future actions)

If you can predict someone is a vandal or troll, don’t let them change pages, or
only let them post to Ye Flaming Pitte of Flamage.

We can to reasonable satisfaction authenticate a token: only grant that
identity to visitors who bear that token. So this part is fine:

person (token)<- identity

But we have no control over authentication token – identity correspondence.
This part is broken:

person x (token)<- identity

The only one who does have that control is the person behind that identity.
They can reasonably guarantee

person >(token)< identity

If that person is going to be in your community, they have an interest in their
identity: they want to be known as someone who isn’t a punk, or doesn’t troll,
or does troll and better than anyone, or won’t rat you out to the cops. The
actions of a person are moderated by their interest in maintaining their

past actions → reputation →person

So give up authorization in favor of auditing and recoverability, and authorize
based on reputation — on the past behavior and vouchsafes offered by the

reputation → trust → permissions →actions

They want to know that they have full control of their identity; among other
things, privacy and an understanding that nobody can act without permission on
their behalf. In fact, we can assure that only a token-holder can assume the
corresponding identity:

person →(token)<→identity →(trust) actions →reputation →person


reputation →trust

So we need to

  • Understand and encourage how their security interests aligns with ours,
  • Understand how it doesn’t, and be robust in the face of that; and
  • Recover gracefully if it goes wrong.

Instead of

authorization → user → token → identity

we assign roles based on

authorization <- trust <- reputation <- identity <- token <- person