summaryrefslogtreecommitdiff
path: root/config/initializers
diff options
context:
space:
mode:
authorsimon <simon@zagal.(none)>2009-02-08 23:15:11 +0100
committerhukl <hukl@eight.local>2009-02-15 20:22:01 +0100
commit9f94a70c3e3d9bf766cb9663b0a904d30a190d85 (patch)
tree4b4bbf567ec60a939d024b083b478d72476700a5 /config/initializers
parent48ffd4eb446bcaeba7651758ec3002f342702249 (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.rb37
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
19REST_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
37REST_AUTH_DIGEST_STRETCHES = 10