h1. Security from the perspective of a community site.

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

* "The OWASP Guide to Building Secure Web Applications":http://www.owasp.org/index.php/Category:OWASP_Guide_Project
* "Secure Programming for Linux and Unix HOWTO":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html
* "Core Security Patterns":http://www.coresecuritypatterns.com/patterns.htm
* Stephen Downes' article on "Authentication and Identification":http://www.downes.ca/post/12

h2. Snazzy Diagram

!http://github.com/technoweenie/restful-authentication/tree/master/notes/SecurityFramework.png?raw=true!:http://github.com/technoweenie/restful-authentication/tree/master/notes/SecurityFramework.png

(in notes/SecurityFramework.png)

h2. Terms

* Identification: Assign this visitor a name and an associated identity
  (picture, website, favorite pokemon, trust metric, security roles).
  
  bq. "Behold. I am not Gandalf the Grey, whom you betrayed, I am Gandalf the White,
  who has returned from death." -- Tolkien

* Authentication: Verify this visitor matches the claimed identity.

  bq. "My name is Werner Brandis. My voice is my password. Verify me." -- Sneakers

* Authorization: Given a request (Actions+Resource+Environment), decide if it's safe.

  bq. "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: Confidence this visitor will act reliably.
  
  bq. "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

** Reputation from Trust Network: Award trust to this visitor based on what other trusted parties say.

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

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

* Access control
  
** Role
  * http://en.wikipedia.org/wiki/Role-based_access_control
  * "Role-Based Access Control FAQ":http://csrc.nist.gov/groups/SNS/rbac/faq.html
  * "Role Based Access Control and Role Based Security":http://csrc.nist.gov/groups/SNS/rbac/ from the NIST Computer Security Division


* Auditing & Recovery

h2. Concept

@  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.
bq. "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
reputation:
  
    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
identity,
  
    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

poop

    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