diff options
| author | simon <simon@zagal.(none)> | 2009-02-08 23:15:11 +0100 |
|---|---|---|
| committer | hukl <hukl@eight.local> | 2009-02-15 20:22:01 +0100 |
| commit | 9f94a70c3e3d9bf766cb9663b0a904d30a190d85 (patch) | |
| tree | 4b4bbf567ec60a939d024b083b478d72476700a5 /config/initializers | |
| parent | 48ffd4eb446bcaeba7651758ec3002f342702249 (diff) | |
* initial commit of the stripped restful-authentication
* http basic auth and login from cookie have been removed
* no it does not work yet, it's so f*cking secure, it won't even let legitimate users login
Diffstat (limited to 'config/initializers')
| -rw-r--r-- | config/initializers/site_keys.rb | 37 |
1 files changed, 37 insertions, 0 deletions
diff --git a/config/initializers/site_keys.rb b/config/initializers/site_keys.rb new file mode 100644 index 0000000..c66fee2 --- /dev/null +++ b/config/initializers/site_keys.rb | |||
| @@ -0,0 +1,37 @@ | |||
| 1 | # A Site key gives additional protection against a dictionary attack if your | ||
| 2 | # DB is ever compromised. With no site key, we store | ||
| 3 | # DB_password = hash(user_password, DB_user_salt) | ||
| 4 | # If your database were to be compromised you'd be vulnerable to a dictionary | ||
| 5 | # attack on all your stupid users' passwords. With a site key, we store | ||
| 6 | # DB_password = hash(user_password, DB_user_salt, Code_site_key) | ||
| 7 | # That means an attacker needs access to both your site's code *and* its | ||
| 8 | # database to mount an "offline dictionary attack.":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html | ||
| 9 | # | ||
| 10 | # It's probably of minor importance, but recommended by best practices: 'defense | ||
| 11 | # in depth'. Needless to say, if you upload this to github or the youtubes or | ||
| 12 | # otherwise place it in public view you'll kinda defeat the point. Your users' | ||
| 13 | # passwords are still secure, and the world won't end, but defense_in_depth -= 1. | ||
| 14 | # | ||
| 15 | # Please note: if you change this, all the passwords will be invalidated, so DO | ||
| 16 | # keep it someplace secure. Use the random value given or type in the lyrics to | ||
| 17 | # your favorite Jay-Z song or something; any moderately long, unpredictable text. | ||
| 18 | # TODO: Change the site key when deploying | ||
| 19 | REST_AUTH_SITE_KEY = 'THIS_KEY_SHOULD_BE_CHANGED_UPON_DEPLOYMENT!!!1ELF' | ||
| 20 | |||
| 21 | # Repeated applications of the hash make brute force (even with a compromised | ||
| 22 | # database and site key) harder, and scale with Moore's law. | ||
| 23 | # | ||
| 24 | # bq. "To squeeze the most security out of a limited-entropy password or | ||
| 25 | # passphrase, we can use two techniques [salting and stretching]... that are | ||
| 26 | # so simple and obvious that they should be used in every password system. | ||
| 27 | # There is really no excuse not to use them." http://tinyurl.com/37lb73 | ||
| 28 | # Practical Security (Ferguson & Scheier) p350 | ||
| 29 | # | ||
| 30 | # A modest 10 foldings (the default here) adds 3ms. This makes brute forcing 10 | ||
| 31 | # times harder, while reducing an app that otherwise serves 100 reqs/s to 78 signin | ||
| 32 | # reqs/s, an app that does 10reqs/s to 9.7 reqs/s | ||
| 33 | # | ||
| 34 | # More: | ||
| 35 | # * http://www.owasp.org/index.php/Hashing_Java | ||
| 36 | # * "An Illustrated Guide to Cryptographic Hashes":http://www.unixwiz.net/techtips/iguide-crypto-hashes.html | ||
| 37 | REST_AUTH_DIGEST_STRETCHES = 10 | ||
