Skip to content
Browse files

Organized notes

  • Loading branch information...
1 parent a2732fb commit c394d99e296ab03e70f2ae052deec766ab47fa89 Philip (flip) Kromer committed May 18, 2008
View
56 CHANGELOG
@@ -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":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
+* http://www.coresecuritypatterns.com/patterns.htm
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
http://dev.rubyonrails.org/changeset/8987 lands.
-* cookies, just like session tokens, should be refreshed each time we cross the
- logged out/in barrier http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens
+
+* cookies are now refreshed each time we cross the logged out/in barrier
+ http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens
+ http://palisade.plynt.com/issues/2004Jul/safe-auth-practices/
+
* !!!! 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.
+change. This says we _should_ reset the session:
+
+ (http://tinyurl.com/5vdvuq) 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.":http://agilewebdevelopment.com/plugins/recaptcha)
- "De-proxy-ficate IP address": http://wiki.codemongers.com/NginxHttpRealIpModule
-
-* 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":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html)
View
23 README
@@ -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":http://github.com/mrflip/restful-authentication/wikis/home 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":http://github.com/mrflip/restful-authentication/tree/master -- look there for the latest version.
+The wiki versions are taken (manually) from there.
+
+===========================================================================
+
Restful Authentication Generator
====
View
15 TODO
@@ -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.":http://agilewebdevelopment.com/plugins/recaptcha)
+ "De-proxy-ficate IP address": http://wiki.codemongers.com/NginxHttpRealIpModule
+
+* 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":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html)
+
+* Log HTTP request on authentication / authorization failures
+ http://palisade.plynt.com/issues/2004Jul/safe-auth-practices
View
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
end
end
+ #
+ # 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
View
2 notes/README-AccessControl.txt
@@ -0,0 +1,2 @@
+
+See the notes in Authorization
View
153 notes/README-Authorization.txt
@@ -0,0 +1,153 @@
+h2. Authorization
+
+"Best Practices for Authorization":http://www.owasp.org/index.php/Guide_to_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 http://en.wikipedia.org/wiki/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":http://www.amazon.com/Security-Patterns-Integrating-Engineering-Software/dp/0470858842
+by M Schumacher ("website for book":http://www.securitypatterns.org/)
+
+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":http://www.coresecuritypatterns.com/patterns.htm 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":http://www.nsitonline.in/hemant/stuff/xacml/XACML%20Tutorial%20with%20a%20Use%20Case%20Scenario%20for%20Academic%20Institutions.htm
+
+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)
+
View
81 notes/README-RailsPlugins.txt
@@ -0,0 +1,81 @@
+h1. Rails Authentication, Authorization and Access Control plugins
+
+h2. Authentication plugins
+
+* http://github.com/technoweenie/restful-authentication/tree/master -- the accepted standard for authentication
+* http://github.com/mrflip/restful-authentication/tree/master -- my fork of restful_authentication with more modularity, more specs and a few security tweaks
+* http://github.com/josh/open_id_authentication/tree/master -- OpenID authentication
+
+h2. Authorization plugins
+
+From
+* http://agilewebdevelopment.com/plugins/tag/security
+* http://www.vaporbase.com/postings/Authorization_in_Rails
+
+
+== maybe ==================================================================
+
+* http://github.com/jbarket/restful-authorization/tree/master
+
+* http://agilewebdevelopment.com/plugins/rolerequirement
+ http://code.google.com/p/rolerequirement/
+ http://rolerequirement.googlecode.com/svn/tags/role_requirement/
+ 9 votes
+
+* http://github.com/ezmobius/acl_system2/
+ http://agilewebdevelopment.com/plugins/acl_system
+ http://opensvn.csie.org/ezra/rails/plugins/dev/acl_system2/
+ last touched 2006
+ 57 votes on AWD
+ * also: http://agilewebdevelopment.com/plugins/acl_system2_ownership
+
+ 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)
+ http://www.vaporbase.com/postings/Authorization_in_Rails
+ http://opensvn.csie.org/mabs29/plugins/simple_access_control
+
+* Active ACL
+ http://phpgacl.sourceforge.net/demo/phpgacl/docs/manual.html
+ (Access-matrix driven)
+
+* http://github.com/aiwilliams/access_controlled_system
+
+* http://agilewebdevelopment.com/plugins/access
+
+* http://robzon.aenima.pl/2007/12/base-auth-is-out.html
+ http://agilewebdevelopment.com/plugins/base_auth
+ http://base-auth.googlecode.com/svn/trunk/
+ 40 votes
+
+* http://agilewebdevelopment.com/plugins/authorization
+ http://www.writertopia.com/developers/authorization
+ http://github.com/DocSavage/rails-authorization-plugin/tree/master
+ Opaque policy descriptions
+ 19 votes
+
+* http://github.com/shuber/access_control_list/
+ Not much there yet
+
+* https://opensvn.csie.org/traccgi/tobionrails
+ http://agilewebdevelopment.com/plugins/access_control
+ http://opensvn.csie.org/tobionrails/plugins/access_control
+ last touched 1 year ago
+
+* http://github.com/mdarby/restful_acl/
+ -- google code too --
+ Just does REST? More of an app than a plugin.
+
+* http://github.com/stonean/lockdown/tree/master
+ http://lockdown.rubyforge.org
+ http://groups.google.com/group/stonean_lockdown?hl=en
+ "Lockdown stores an array of access rights in the session"
+
+h2. Trust / Validation etc. plugins
+
+
+* http://agilewebdevelopment.com/plugins/recaptcha
View
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,":http://www.downes.ca/post/12 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
+ - 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":http://www.trustlet.org/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":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.
+
+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@
+
View
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." -- http://www.owasp.org/index.php/Guide_to_Authorization
+
+* how I authenticated: for instance, 'logged in by cookie' << 'logged in by password'
+
View
BIN notes/SecurityFramework.graffle
Binary file not shown.
View
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.