forked from technoweenie/restful-authentication
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* 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) * put length constraints in migration too * password in 6, 40 * Trivial email validation * Added site key to generator, users.yml. * Made site key generation idempotent in the most crude and hackish way h4. 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. * Stretch 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. ... 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 More: * http://www.owasp.org/index.php/Hashing_Java * "An Illustrated Guide to Cryptographic Hashes":http://www.unixwiz.net/techtips/iguide-crypto-hashes.html
- Loading branch information
Philip (flip) Kromer
committed
May 18, 2008
1 parent
c855a16
commit 53f3f3b
Showing
9 changed files
with
339 additions
and
46 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
|
||
# 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. | ||
REST_AUTH_SITE_KEY = '<%= $rest_auth_site_key_from_generator %>' | ||
|
||
# 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 = <%= $rest_auth_digest_stretches_from_generator %> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.