From 9f94a70c3e3d9bf766cb9663b0a904d30a190d85 Mon Sep 17 00:00:00 2001 From: simon Date: Sun, 8 Feb 2009 23:15:11 +0100 Subject: * 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 --- config/initializers/site_keys.rb | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 config/initializers/site_keys.rb (limited to 'config/initializers') 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 @@ +# 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. +# TODO: Change the site key when deploying +REST_AUTH_SITE_KEY = 'THIS_KEY_SHOULD_BE_CHANGED_UPON_DEPLOYMENT!!!1ELF' + +# Repeated applications of the hash make brute force (even with a compromised +# database and site key) harder, and scale with Moore's law. +# +# 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." http://tinyurl.com/37lb73 +# Practical Security (Ferguson & Scheier) p350 +# +# A modest 10 foldings (the default here) adds 3ms. This makes brute forcing 10 +# times harder, while reducing an app that otherwise serves 100 reqs/s to 78 signin +# reqs/s, an app that does 10reqs/s to 9.7 reqs/s +# +# More: +# * http://www.owasp.org/index.php/Hashing_Java +# * "An Illustrated Guide to Cryptographic Hashes":http://www.unixwiz.net/techtips/iguide-crypto-hashes.html +REST_AUTH_DIGEST_STRETCHES = 10 -- cgit v1.3