restful_authentication 1.1.6

data/notes/RailsPlugins.txt

@@ -0,0 +1,78 @@
+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
+
+* 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

data/notes/SecurityPatterns.txt

@@ -0,0 +1,163 @@
+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
+

data/notes/Tradeoffs.txt

@@ -0,0 +1,126 @@
+Guides to best practices:
+* "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]]
+
+***************************************************************************
+h2. Session resetting
+
+Best practices recommend that you regenerate all session tokens (for us, the
+browser session ID and the remember_token cookie) on any privilege change (for
+us, logging in or logging out) -- see http://tinyurl.com/5vdvuq.  This release
+properly regenerates remember_token cookies, but does *not* by default
+reset_session.
+
+Calling reset_session can interact with Form Authentication tokens (a *much*
+more important security feature).  If a visitor logs in but has a form open in
+another tab, or uses the back button to pull one up from their history (perhaps
+the one that required them to log in), they will get the exceedingly unpleasant
+Request Forgery error.  Imagine spending twenty minutes crafting a devastating
+critique of this week's Battlestar Galactica episode, finding you need to log in
+before posting -- but then getting a Request Forgery when you re-attempt the
+post.  Frak!  Thus, it's disabled by default.
+
+On the other hand, this does moderately reduce your defense-in-depth against a
+"Cross-Site Request Forgery":http://en.wikipedia.org/wiki/CSRF attack.  To
+enable session_resetting, look for any
+   # reset session
+lines in the app/controllers/session_controller.rb and
+app/controllers/users_controller.rb and uncomment them.
+
+***************************************************************************
+h2. Site Key
+
+A Site key gives additional protection against a dictionary attack if your
+DB is ever compromised.  With no site key, we store
+  DB_password = hash(user_password, DB_user_salt)
+If your database were to be compromised you'd be vulnerable to a dictionary
+attack on all your stupid users' passwords.  With a site key, we store
+  DB_password = hash(user_password, DB_user_salt, Code_site_key)
+That means an attacker needs access to both your site's code *and* its
+database to mount an "offline dictionary attack.":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html
+
+It's probably of minor importance, but recommended by best practices: 'defense
+in depth'.  Needless to say, if you upload this to github or the youtubes or
+otherwise place it in public view you'll kinda defeat the point.  Your users'
+passwords are still secure, and the world won't end, but defense_in_depth -= 1.
+
+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.
+
+***************************************************************************
+h2. Password stretching
+
+If someone were to capture your user accounts database, they could farm it out
+for brute-force or dictionary-attack password cracking.  "Password Stretching"
+makes brute force (even with a compromised database and site key) attacks
+harder, and scales with Moore's law.  Basically, you apply the password
+encryption process several times, meaning that each brute-force attempt takes
+that much longer.  Hash your password ten times, and a brute-force attack takes
+ten times longer; hash 100,000 times and an attack takes 100,000 times longer.
+
+  bq. "To squeeze the most security out of a limited-entropy password or
+  passphrase, we can use two techniques [salting and stretching]... that are so
+  simple and obvious that they should be used in every password system.  There
+  is really no excuse not to use them. ... Choose stretching factor so computing
+  K from (salt, passwd) takes 200-1000 ms. Store r with the user's password, and
+  increase it as computers get faster." -- http://tinyurl.com/37lb73
+  Practical Security (Ferguson & Scheier) p350
+
+Now, adding even a 0.2s delay to page requests isn't justifiable for most online
+applications, and storing r is unnecessary (at least on your first design
+iteration).  But 
+  On a 1G Slicehost already under moderate load:
+  irb(main):005:0> puts Time.now; (10**6).times{ secure_digest(Time.now, rand) }; puts Time.now
+  Fri May 16 08:26:16 +0000 2008
+  Fri May 16 08:30:58 +0000 2008
+  => 280s/1M ~= 0.000_3 ms / digest
+A modest 10 (the default here) foldings makes brute forcing, even given the site
+key and database, 10 times harder at a 3ms penalty.  An app that otherwise
+serves 100 reqs/s is reduced to 78 signin reqs/s; an app that does 10reqs/s is
+reduced to 9.7 signin reqs/s
+
+* http://www.owasp.org/index.php/Hashing_Java
+* "An Illustrated Guide to Cryptographic Hashes":http://www.unixwiz.net/techtips/iguide-crypto-hashes.html
+
+The default of 10 is a reasonable compromise, but the security-paranoid and
+resource-rich may consider increasing REST_AUTH_DIGEST_STRETCHES to match the
+one-second best-practices value, while those with existing userbases (whose
+passwords would otherwise no longer work) should leave the value at one.
+
+***************************************************************************
+h2. Token regeneration
+
+The session and the remember_token should both be expired and regenerated
+every time we cross the logged out / logged in barrier by either password
+or cookie.  ("To reduce the risk from session hijacking":http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens
+and brute force attacks, the HTTP server can seamlessly expire and
+regenerate tokens. This decreases the window of opportunity for a replay or
+brute force attack.)  It does mean we set the cookie more often.
+
+  http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens
+  http://palisade.plynt.com/issues/2004Jul/safe-auth-practices/
+
+
+***************************************************************************
+h2. Field validation
+
+We restrict login names to only contain the characters
+<nowiki>A-Za-z0-9.-_@</nowiki> This allows (most) email addresses and is safe
+for urls, database expressions (the at sign, technically reserved in a url, will
+survive in most browsers).  If you want to be more permissive:
+*  "URL-legal characters":http://www.blooberry.com/indexdot/html/topics/urlencoding.htm are <nowiki>-_.!~*'()</nowiki>
+*  "XML-legal characters":http://www.sklar.com/blog/archives/96-XML-vs.-Control-Characters.html are <nowiki>Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]</nowiki>
+*  "Email-address legal characters":http://tools.ietf.org/html/rfc2822#section-3.4.1 are <nowiki>0-9a-zA-Z!#\$%\&\'\*\+_/=\?^\-`\{|\}~\.</nowiki> but see "this discussion of what is sane"http://www.regular-expressions.info/email.html (as opposed to legal)
+
+We restrict email addresses to match only those actually seen in the wild,
+invalidating some that are technically allowed (characters such as % and ! that
+date back to UUCP days.  The line to allow all RFC-2822 emails is commented out,
+so feel free to enable it, or remove this validation.  See "this discussion of
+what is sane"http://www.regular-expressions.info/email.html as opposed to what
+is legal.  Also understand that this is just a cursory bogus-input check --
+there's no guarantee that this email matches an account or is even well-formed.
+
+If you change these validations you should change the RSpec tests as well.
+

data/notes/Trustification.txt

@@ -0,0 +1,49 @@
+See also
+* "Trustlet Wiki":http://www.trustlet.org/wiki
+
+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'
+

data/restful_authentication.gemspec

@@ -0,0 +1,32 @@
+# -*- encoding: utf-8 -*-
+
+Gem::Specification.new do |s|
+  s.name = %q{restful_authentication}
+  s.version = "1.1.6"
+
+  s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
+  s.authors = ["RailsJedi", "Rick Olson"]
+  s.date = %q{2009-12-09}
+  s.description = %q{This widely-used plugin provides a foundation for securely managing user.}
+  s.email = %q{railsjedi@gmail.com}
+  s.extra_rdoc_files = ["README.textile"]
+  s.files = ["CHANGELOG", "generators", "generators/authenticated", "generators/authenticated/authenticated_generator.rb", "generators/authenticated/lib", "generators/authenticated/lib/insert_routes.rb", "generators/authenticated/templates", "generators/authenticated/templates/_model_partial.html.erb", "generators/authenticated/templates/activation.erb", "generators/authenticated/templates/authenticated_system.rb", "generators/authenticated/templates/authenticated_test_helper.rb", "generators/authenticated/templates/controller.rb", "generators/authenticated/templates/features", "generators/authenticated/templates/features/accounts.feature", "generators/authenticated/templates/features/sessions.feature", "generators/authenticated/templates/features/step_definitions", "generators/authenticated/templates/features/step_definitions/ra_env.rb", "generators/authenticated/templates/features/step_definitions/user_steps.rb", "generators/authenticated/templates/helper.rb", "generators/authenticated/templates/login.html.erb", "generators/authenticated/templates/machinist_spec.rb", "generators/authenticated/templates/machinist_test.rb", "generators/authenticated/templates/mailer.rb", "generators/authenticated/templates/migration.rb", "generators/authenticated/templates/model.rb", "generators/authenticated/templates/model_controller.rb", "generators/authenticated/templates/model_helper.rb", "generators/authenticated/templates/model_helper_spec.rb", "generators/authenticated/templates/observer.rb", "generators/authenticated/templates/signup.html.erb", "generators/authenticated/templates/signup_notification.erb", "generators/authenticated/templates/site_keys.rb", "generators/authenticated/templates/spec", "generators/authenticated/templates/spec/blueprints", "generators/authenticated/templates/spec/blueprints/user.rb", "generators/authenticated/templates/spec/controllers", "generators/authenticated/templates/spec/controllers/access_control_spec.rb", "generators/authenticated/templates/spec/controllers/authenticated_system_spec.rb", "generators/authenticated/templates/spec/controllers/sessions_controller_spec.rb", "generators/authenticated/templates/spec/controllers/users_controller_spec.rb", "generators/authenticated/templates/spec/fixtures", "generators/authenticated/templates/spec/fixtures/users.yml", "generators/authenticated/templates/spec/helpers", "generators/authenticated/templates/spec/helpers/users_helper_spec.rb", "generators/authenticated/templates/spec/models", "generators/authenticated/templates/spec/models/user_spec.rb", "generators/authenticated/templates/tasks", "generators/authenticated/templates/tasks/auth.rake", "generators/authenticated/templates/test", "generators/authenticated/templates/test/functional_test.rb", "generators/authenticated/templates/test/mailer_test.rb", "generators/authenticated/templates/test/model_functional_test.rb", "generators/authenticated/templates/test/unit_test.rb", "generators/authenticated/USAGE", "lib", "lib/authentication", "lib/authentication/by_cookie_token.rb", "lib/authentication/by_password.rb", "lib/authentication.rb", "lib/authorization", "lib/authorization/aasm_roles.rb", "lib/authorization/stateful_roles.rb", "lib/authorization.rb", "lib/restful_authentication.rb", "lib/trustification", "lib/trustification/email_validation.rb", "lib/trustification.rb", "LICENSE", "notes", "notes/AccessControl.txt", "notes/Authentication.txt", "notes/Authorization.txt", "notes/RailsPlugins.txt", "notes/SecurityFramework.graffle", "notes/SecurityFramework.png", "notes/SecurityPatterns.txt", "notes/Tradeoffs.txt", "notes/Trustification.txt", "pkg", "Rakefile", "README.textile", "restful_authentication.gemspec", "TODO"]
+  s.homepage = %q{http://github.com/jeremydurham/restful-authentication}
+  s.rdoc_options = ["--main", "README.textile"]
+  s.require_paths = ["lib"]
+  s.rubygems_version = %q{1.3.5}
+  s.summary = %q{Generates code for user login and authentication}
+
+  if s.respond_to? :specification_version then
+    current_version = Gem::Specification::CURRENT_SPECIFICATION_VERSION
+    s.specification_version = 2
+
+    if Gem::Version.new(Gem::RubyGemsVersion) >= Gem::Version.new('1.2.0') then
+      s.add_runtime_dependency(%q<rails>, ["~> 2.3.4"])
+    else
+      s.add_dependency(%q<rails>, ["~> 2.3.4"])
+    end
+  else
+    s.add_dependency(%q<rails>, ["~> 2.3.4"])
+  end
+end