Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Browse files

Organized notes

  • Loading branch information...
commit c394d99e296ab03e70f2ae052deec766ab47fa89 1 parent a2732fb
Philip (flip) Kromer authored
@@ -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.
Please sign in to comment.
Something went wrong with that request. Please try again.