Security Patterns
Better than anything you’ll read below on the subject:
- The OWASP Guide to Building Secure Web Applications
- Secure Programming for Linux and Unix HOWTO
- http://www.coresecuritypatterns.com/patterns.htm
- Authentication and Identification, by Stephen Downes Highly Recommended
(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
– http://en.wikipedia.org/wiki/Authorization
- 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
- Role
– http://en.wikipedia.org/wiki/Role-based_access_control
– Role-Based Access Control FAQ
– Role Based Access Control and Role Based Security from the NIST Computer Security Division
- 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) <- actionsThat 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.
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
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:
But we have no control over authentication token – identity correspondence.
This part is broken:
The only one who does have that control is the person behind that identity.
They can reasonably guarantee
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:
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,
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:
poop
reputation →trustSo 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 → identitywe assign roles based on
authorization <- trust <- reputation <- identity <- token <- person