Skip to content
Browse files

Organized notes

  • Loading branch information...
1 parent a2732fb commit c394d99e296ab03e70f2ae052deec766ab47fa89 Philip (flip) Kromer committed May 18, 2008
@@ -1,9 +1,8 @@
-Changes since fork from technoweenie's branch
-I've made a few security changes based on best practices recommended in
+Following best practices recommended in
* "The OWASP Guide to Building Secure Web Applications":
* "Secure Programming for Linux and Unix HOWTO":
They're described in more detail below.
@@ -45,8 +44,11 @@ h3. authenticated_system
* added uniform logout! methods
* format.any (as found in access_denied) doesn't work until lands.
-* cookies, just like session tokens, should be refreshed each time we cross the
- logged out/in barrier
+* cookies are now refreshed each time we cross the logged out/in barrier
* !!!! Possibly stupid !!!
Made current_user and logged_in? be public methods. I did this for the worst
possible reason -- so that I could write story steps that call it directly.
@@ -87,9 +89,32 @@ resubmiting an earlier form will. I think it's Mostly Harmless but I've left it
commented out.
I'd like to get the advice of someone who understands CSRF better than I on this
+change. This says we _should_ reset the session:
+ ( Regenerate session IDs upon privilege
+ changes. Most Web applications assign a session ID upon the first request for
+ a URL, even for anonymous users. If the user logs in, then the application
+ should create and assign a new session ID to the user. This not only
+ represents that the user has authenticated, but it reduces the chances of
+ eavesdropping attacks if the initial access to the application wasn't
+ conducted over SSL. It also mitigates against session fixation attacks
+ discussed earlier in the chapter, where an attacker goes to a site and gets a
+ session ID, then e-mails it to the victim and allows them to log in using the
+ ID that the attacker already knows
+h2. Non-backwards compatible Changes
+Here are a few changes that increase "Defense in Depth" but will invalidate
+existing login/passwords without a migration.
-h3. Non-backwards compatible Changes
+* If you have an existing site, none of these changes are compelling enough to
+ warrant migrating your userbase.
+* If you are generating for a new site, all of these changes are low-impact.
+ You should apply them.
+h3. minor changes
* login in /\w+\.\-_@/ This allows (most) email addresses and is safe for urls, database expressions (@, technically reserved in a url, will survive in most browsers)
If you want to be more permissive:
@@ -102,7 +127,7 @@ h3. Non-backwards compatible Changes
* Added site key to generator, users.yml.
* Made site key generation idempotent in the most crude and hackish way
-h4. Site key
+h3. Site key
A Site key gives additional protection against a dictionary attack if your
DB is ever compromised. With no site key, we store
@@ -122,7 +147,7 @@ Please note: if you change this, all the passwords will be invalidated, so DO
keep it someplace secure. Use the random value given or type in the lyrics to
your favorite Jay-Z song or something; any moderately long, unpredictable text.
-* Stretch
+h3. Password Encryption Stretching
Repeated applications of the hash make brute force (even with a compromised
database and site key) harder, and scale with Moore's law.
@@ -166,16 +191,3 @@ h3. Stories
* added them
-h3. Authentication security projects for a later date
-A couple little projects
-* Track 'failed logins this hour' and demand a captcha after say 5 failed logins
- ("RECAPTCHA plugin.":
- "De-proxy-ficate IP address":
-* Make cookie spoofing a little harder: we set the user's cookie to
- (remember_token), but store digest(remember_token, request_IP). A CSRF cookie
- spoofer has to then at least also spoof the user's originating IP
- (see "Secure Programs HOWTO":
@@ -1,3 +1,26 @@
+This is mrflip's fork of "technoweenie's restful-authentication":/technoweenie/restful-authentication/
+plugin. The goal is to
+* Modularize to match security design patterns:
+** Authentication (currently: password, browser cookie token, HTTP basic)
+** Trust metric (email validation)
+** Authorization (stateful roles)
+* Add full RSpec and Story test suite
+* Leave a flexible framework that will play nicely with other access control / policy definition / trust metric plugins
+See the "wiki": for notes on
+* "Security Design Patterns":Security-Patterns
+* [[Authentication]] -- Lets a visitor identify herself (and lay claim to her corresponding Roles and measure of Trust)
+* "Trust Metrics":Trustification -- Confidence we can rely on the outcomes of this visitor's actions.
+* "Authorization and Policy":Authorization -- Based on trust and identity, what actions may this visitor perform?
+* "Access Control":Access-Control -- How the Authorization policy is actually enforced in your code (hopefully without turning it into a spaghetti of if thens)
+* "Rails Security Plugins":RailsPlugins -- for Authentication, Trust, Authorization and Access Control
+These best versions are in the notes/ directory in the "source code": -- look there for the latest version.
+The wiki versions are taken (manually) from there.
Restful Authentication Generator
@@ -0,0 +1,15 @@
+h3. Authentication security projects for a later date
+* Track 'failed logins this hour' and demand a captcha after say 5 failed logins
+ ("RECAPTCHA plugin.":
+ "De-proxy-ficate IP address":
+* Make cookie spoofing a little harder: we set the user's cookie to
+ (remember_token), but store digest(remember_token, request_IP). A CSRF cookie
+ spoofer has to then at least also spoof the user's originating IP
+ (see "Secure Programs HOWTO":
+* Log HTTP request on authentication / authorization failures
6 lib/authentication/by_cookie_token.rb
@@ -1,3 +1,4 @@
+# -*- coding: mule-utf-8 -*-
module Authentication
module ByCookieToken
@@ -47,6 +48,11 @@ def refresh_token
+ #
+ # Deletes the server-side record of the authentication token. The
+ # client-side (browser cookie) and server-side (this remember_token) must
+ # always be deleted together.
+ #
def forget_me
self.remember_token_expires_at = nil
self.remember_token = nil
2 notes/README-AccessControl.txt
@@ -0,0 +1,2 @@
+See the notes in Authorization
153 notes/README-Authorization.txt
@@ -0,0 +1,153 @@
+h2. Authorization
+"Best Practices for Authorization":
+# auth system should deny by default
+# Principle of least privilege (fine-grain)
+# each non-anonymous entry point have an access control check
+# authorization check at or near the beginning of code implementing sensitive activities
+# Ensure that Model code checks to ensure that the requesting user should have access to the protected resource.
+# Reauthorization for high value activities or after idle out
+# If custom code is required to perform authorization functions, consider
+ fail-safe authentication and exception handling – ensure that if an exception
+ is thrown, the user is logged out or at least prevented from accessing the
+ protected resource or function.
+# Well written applications centralize access control routines, so if any bugs
+ are found, they can be fixed once and the results apply throughout the
+ application immediately.
+h2. Authorization in a trust context
+* remember: goal is **prediction** not **control**
+h2. Patterns for Policy definition / Authorization / access control
+*Reference Monitor (SecPatt p256)
+** Set of authorization rules
+** Actor, Action, Resource => Monitor+(rules) => ctrlr
+* Role based:
+ subj, role, right. action, resource
+ RBAC, access is controlled at the system level, outside of the user's control
+* Filter based
+ User x Controller x Action x Params --
+* Object based
+ model security delegation
+* Access Control Matrix
+* CommandProcessor pattern (DSL approach)
+* DENY FROM ... / ALLOW FROM ... approach
+* Capability based control: bundle together the designation of an object and the permission to access that object
+ ie. I can name it if and only if I am allowed to get at it.
+h2. Notes from "Security patterns":
+by M Schumacher ("website for book":
+Reference Monitor (SecPatt p256)
+ * Set of authorization rules
+ * Actor, Action, Resource => Monitor+(rules) => ctrlr
+= Full access with Errors (SecPatt p305)
+* Users should not be able to view data or perform operations for which they
+ have no permissions.
+* Hiding an available and accessible function is inappropriate, because users
+ must be able to see what they can do.
+* The visual appeal and usability of a graphical user interface (GUI) can be de-
+ graded by varying layouts depending on the (current) access rights of a
+ user. For example, blank space might appear for some users where others see
+ options they can access, or sequence and number of menu items might differ,
+ depending on the current user’s rights, and thus ‘blind’ operation of the menu
+ by an expe- rienced user is no longer possible.
+* Showing currently unavailable functions can tease users to into upgrading
+ their access rights, for example by paying for the access or buying a license
+ after us- ing a demo version.
+* Trial and error are ineffective means of learning which functions are
+ accessible. Invoking an operation only to learn that it doesn’t work with
+ your access rights is confusing.
+* The privilege grouping of the typical user community might not be known at the
+ design time of the GUI, and it might change over time, for example through
+ organizational or business process changes, so that providing a few special
+ modes of the GUI depending on the corresponding user roles is inappropriate.
+* Checking whether a function is allowed by a user is most efficient, robust and
+ secure, if done by the function itself—at least the code performing the checks
+ is then closely related to the code performing the subsequent operation
+ afterwards.
+h2. Outcomes / Obligations
+-- forbid
+-- ask for trust escalation (eg log in, prove_as_human, validate_email, are_you_sure, send_me_ten_cents)
+-- drag ass
+-- permit
+-- reinterpret past actions based on future evolution of trust
+-- prioritize changesets based on trust.
+h2. Notes from "Core Security Patterns": website
+# Authentication Enforcer who the hell are you
+# Intercepting Validator Is your request well-formed
+# Authorization Enforcer Are you allowed to do that
+# Secure Logger Know what's happening/happened
+h2. notes from "XACML":
+PolicySets [Policy Combining Algorithm]
+Policy [Rule Combining Algorithm] (defines access to particular resources.)
+# Target
+## Subject Attributes
+## Resource Attributes
+## Action Attributes
+## Environment Attributes
+# Rule [Effect] Identify various conditions or cases under which a policy may become applicable
+## Subject Attributes user who has made an access request
+## Resource Attributes object to which access is requested
+## Action Attributes action the subject wants to take on the resource
+## Environment Attributes request environment (time of day, ip, etc)
+## Conditions
+# Obligations
+Roles -- student, janitor, dean, stranger, ...
+Branches -- Departments, etc.
+* Examine applicable rules until you get an outcome, failure or passes thru (in which case rejected)
+* Rule combining Algorithms
+* Obligations -- things to do once requests have been denied or permitted
+Reference Monitor (SecPatt p256)
+ * Set of authorization rules
+ * Actor, Action, Resource --> Monitor+(rules) --> ctrlr
+# ask for permissions on arbitrary (subject, action, resource)
+ * roles
+# get filtered object based on action (:public_info, :admin_info, etc.)
+# attach a rule to a (subject|role, action, resource) triple
+ "subject should have role R"
+ "subject should have role R on resource X"
+ "should meet the
+* Role supervisor:
+ * adds, defines, removes roles. no policy -- just attaches roles to users
+* Policy
+ answers "can Actor do Action to Resource"
+ * Rules
+ * Rule resolution
+ * outcome, obligations.
+ policy definitions can come from many places, go to policy mgr.
+* Hall monitor
+ enforces policy (before filters)
+* Policy observers
+ handle policy obligations
+* Athentication -- identification, really: securely attach visitor to identity
+* Validation -- qualify trust
+* Access control -- define policy
+** Roles
+** Acc. matrix
+* Authorization -- enforce policy (reference monitor ; filter chain)
+* Obligations
+** Audit -- (observer)
81 notes/README-RailsPlugins.txt
@@ -0,0 +1,81 @@
+h1. Rails Authentication, Authorization and Access Control plugins
+h2. Authentication plugins
+* -- the accepted standard for authentication
+* -- my fork of restful_authentication with more modularity, more specs and a few security tweaks
+* -- OpenID authentication
+h2. Authorization plugins
+== maybe ==================================================================
+ 9 votes
+ last touched 2006
+ 57 votes on AWD
+ * also:
+ bq. access_control [:new, :create, :update, :edit] => '(admin | user |
+ moderator)', :delete => 'admin'
+ <% restrict_to "(admin | moderator) & !blacklist" do %>
+ <%= link_to "Admin & Moderator only link", :action =>'foo' %>
+ <% end %>
+* Authorization Recipe (from Rails Recipes #32)
+* Active ACL
+ (Access-matrix driven)
+ 40 votes
+ Opaque policy descriptions
+ 19 votes
+ Not much there yet
+ last touched 1 year ago
+ -- google code too --
+ Just does REST? More of an app than a plugin.
+ "Lockdown stores an array of access rights in the session"
+h2. Trust / Validation etc. plugins
137 notes/README-SecurityPatterns.txt
@@ -0,0 +1,137 @@
+h2. Security from the perspective of a community site.
+Better than anything you'll read by me on the subject: "Authentication and
+Identification,": by Stephen Downes **Highly Recommended**
+h2. Terms
+* 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
+* Role
+ -
+ - "Role-Based Access Control FAQ":
+ - "Role Based Access Control and Role Based Security": 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.
+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
+ 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@
47 notes/README-Trustification.txt
@@ -0,0 +1,47 @@
+Potential Ingredients for a trust metric
+h2. Reputation
+* Web of trust
+* Reputation systems
+** Akismet, Viking, etc.
+* prove_as_human Completing a
+* validate_email
+ logged_in
+ akismet, etc.
+ session duration
+h2. Accountability
+Does the person tied to this identity stand to lose or gain anything based on this action?
+h2. Past history
+* past history
+** we can revisit past trust decisions based on revised trust estimates
+* recency of errors (reduce trust on an application exception)
+h2. Commitment
+* are_you_sure -- ask for con
+* willingness to pay a "hate task" (compute big hash) a la Zed Shaw
+* send_me_one_cent a micropayment
+** shows commitment
+** secondary validation from payment system
+** offsets rist
+h2. Identity Binding
+* Stale sessions
+ bq. "If your application allows users to be logged in for long periods of time
+ ensure that controls are in place to revalidate a user’s authorization to a
+ resource. For example, if Bob has the role of “Top Secret” at 1:00, and at
+ 2:00 while he is logged in his role is reduced to Secret he should not be able
+ to access “Top Secret” data any more." --
+* how I authenticated: for instance, 'logged in by cookie' << 'logged in by password'
BIN notes/SecurityFramework.graffle
Binary file not shown.
BIN notes/SecurityFramework.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit c394d99

Please sign in to comment.
Something went wrong with that request. Please try again.