0
@@ -1,9 +1,8 @@
0
 
0
-Changes since fork from technoweenie's branch
0
-
0
-I've made a few security changes based on best practices recommended in
0
+Following best practices recommended in
0
 * "The OWASP Guide to Building Secure Web Applications":http://www.owasp.org/index.php/Category:OWASP_Guide_Project
0
 * "Secure Programming for Linux and Unix HOWTO":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html
0
+* http://www.coresecuritypatterns.com/patterns.htm
0
 
0
 They're described in more detail below.
0
 
0
@@ -45,8 +44,11 @@ h3. authenticated_system
0
 * added uniform logout! methods
0
 * format.any (as found in access_denied) doesn't work until
0
   http://dev.rubyonrails.org/changeset/8987 lands.
0
-* cookies, just like session tokens, should be refreshed each time we cross the
0
-  logged out/in barrier http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens
0
+  
0
+* cookies are now refreshed each time we cross the logged out/in barrier
0
+  http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens
0
+  http://palisade.plynt.com/issues/2004Jul/safe-auth-practices/
0
+  
0
 * !!!! Possibly stupid !!!
0
   Made current_user and logged_in? be public methods.  I did this for the worst
0
   possible reason -- so that I could write story steps that call it directly.
0
@@ -87,9 +89,32 @@ resubmiting an earlier form will.  I think it's Mostly Harmless but I've left it
0
 commented out.  
0
 
0
 I'd like to get the advice of someone who understands CSRF better than I on this
0
-change.
0
+change.  This says we _should_ reset the session:
0
+
0
+  (http://tinyurl.com/5vdvuq) Regenerate session IDs upon privilege
0
+  changes. Most Web applications assign a session ID upon the first request for
0
+  a URL, even for anonymous users. If the user logs in, then the application
0
+  should create and assign a new session ID to the user. This not only
0
+  represents that the user has authenticated, but it reduces the chances of
0
+  eavesdropping attacks if the initial access to the application wasn't
0
+  conducted over SSL. It also mitigates against session fixation attacks
0
+  discussed earlier in the chapter, where an attacker goes to a site and gets a
0
+  session ID, then e-mails it to the victim and allows them to log in using the
0
+  ID that the attacker already knows
0
+
0
+
0
+
0
+h2. Non-backwards compatible Changes
0
+
0
+Here are a few changes that increase "Defense in Depth" but will invalidate
0
+existing login/passwords without a migration.
0
 
0
-h3. Non-backwards compatible Changes
0
+* If you have an existing site, none of these changes are compelling enough to
0
+  warrant migrating your userbase.
0
+* If you are generating for a new site, all of these changes are low-impact.
0
+  You should apply them.
0
+
0
+h3. minor changes
0
 
0
 * 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)
0
   If you want to be more permissive:
0
@@ -102,7 +127,7 @@ h3. Non-backwards compatible Changes
0
 * Added site key to generator, users.yml.
0
 * Made site key generation idempotent in the most crude and hackish way
0
 
0
-h4. Site key
0
+h3. Site key
0
 
0
 A Site key gives additional protection against a dictionary attack if your
0
 DB is ever compromised.  With no site key, we store
0
@@ -122,7 +147,7 @@ Please note: if you change this, all the passwords will be invalidated, so DO
0
 keep it someplace secure.  Use the random value given or type in the lyrics to
0
 your favorite Jay-Z song or something; any moderately long, unpredictable text.
0
 
0
-* Stretch
0
+h3. Password Encryption Stretching
0
 
0
 Repeated applications of the hash make brute force (even with a compromised
0
 database and site key) harder, and scale with Moore's law.
0
@@ -166,16 +191,3 @@ h3. Stories
0
 
0
 * added them
0
 
0
-
0
-h3. Authentication security projects for a later date
0
-
0
-A couple little projects
0
-
0
-* Track 'failed logins this hour' and demand a captcha after say 5 failed logins
0
-  ("RECAPTCHA plugin.":http://agilewebdevelopment.com/plugins/recaptcha)
0
-  "De-proxy-ficate IP address": http://wiki.codemongers.com/NginxHttpRealIpModule
0
-
0
-* Make cookie spoofing a little harder: we set the user's cookie to
0
-  (remember_token), but store digest(remember_token, request_IP). A CSRF cookie
0
-  spoofer has to then at least also spoof the user's originating IP
0
-  (see "Secure Programs HOWTO":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html)

0
@@ -1,3 +1,26 @@
0
+This is mrflip's fork of "technoweenie's restful-authentication":/technoweenie/restful-authentication/
0
+plugin. The goal is to
0
+
0
+* Modularize to match security design patterns:
0
+** Authentication (currently: password, browser cookie token, HTTP basic)
0
+** Trust metric (email validation) 
0
+** Authorization (stateful roles)
0
+* Add full RSpec and Story test suite
0
+* Leave a flexible framework that will play nicely with other access control / policy definition / trust metric plugins
0
+
0
+See the "wiki":http://github.com/mrflip/restful-authentication/wikis/home for notes on
0
+* "Security Design Patterns":Security-Patterns
0
+* [[Authentication]] -- Lets a visitor identify herself (and lay claim to her corresponding Roles and measure of Trust)
0
+* "Trust Metrics":Trustification -- Confidence we can rely on the outcomes of this visitor's actions.
0
+* "Authorization and Policy":Authorization -- Based on trust and identity, what actions may this visitor perform?
0
+* "Access Control":Access-Control -- How the Authorization policy is actually enforced in your code (hopefully without turning it into a spaghetti of if thens)
0
+* "Rails Security Plugins":RailsPlugins -- for Authentication, Trust, Authorization and Access Control
0
+
0
+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.
0
+The wiki versions are taken (manually) from there.
0
+
0
+===========================================================================
0
+
0
 Restful Authentication Generator
0
 ====
0
 

0
@@ -1,3 +1,4 @@
0
+# -*- coding: mule-utf-8 -*-
0
 module Authentication
0
   module ByCookieToken
0
 
0
@@ -47,6 +48,11 @@ module Authentication
0
         end
0
       end
0
 
0
+      # 
0
+      # Deletes the server-side record of the authentication token.  The
0
+      # client-side (browser cookie) and server-side (this remember_token) must
0
+      # always be deleted together.
0
+      #
0
       def forget_me
0
         self.remember_token_expires_at = nil
0
         self.remember_token            = nil