couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "Security_Features_Overview" by StephaneAlnet
Date Thu, 03 Mar 2011 18:24:15 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "Security_Features_Overview" page has been changed by StephaneAlnet.
The comment on this change is: Added couchdb_password, a script to generate a valid salt /
password_sha pair..
http://wiki.apache.org/couchdb/Security_Features_Overview?action=diff&rev1=19&rev2=20

--------------------------------------------------

  An overview of the security features that CouchDB 0.11 provides out of the box.
  
  == Authentication ==
- 
  CouchDB 0.11 ships with several authentication handlers:
  
   * OAuth authentication handler
@@ -21, +20 @@

  [httpd]
  authentication_handlers = {couch_httpd_oauth, oauth_authentication_handler}, {couch_httpd_auth,
cookie_authentication_handler}, {couch_httpd_auth, default_authentication_handler}
  }}}
- 
  '''Note:''' for testing purposes the authentication handler ''{couch_httpd_auth, null_authentication_handler}''
can be used. It authenticates any request as being originated by a server admin user.
  
  == Authorization ==
- 
  As of CouchDB 0.11, three types of users can be defined:
  
-   * database readers - Defined per database. They can read all types of documents from the
DB, and they can write (and edit) documents to the DB except for design documents.
+  * database readers - Defined per database. They can read all types of documents from the
DB, and they can write (and edit) documents to the DB except for design documents.
  
-   * database admins - Defined per database. They have all the privileges readers have plus
the privileges: write (and edit) design documents, add/remove database admins and readers,
set the database revisions limit (''/somedb/_revs_limit'' API) and execute temporary views
against the database (''/somedb/_temp_view'' API). They can not create a database and neither
delete a database.
+  * database admins - Defined per database. They have all the privileges readers have plus
the privileges: write (and edit) design documents, add/remove database admins and readers,
set the database revisions limit (''/somedb/_revs_limit'' API) and execute temporary views
against the database (''/somedb/_temp_view'' API). They can not create a database and neither
delete a database.
  
-   * server admins - Defined per CouchDB server. They have all the privileges.
+  * server admins - Defined per CouchDB server. They have all the privileges.
  
  Server admins are defined in the ''admins'' section of the .ini configuration files. See
[[Setting_up_an_Admin_account]] for more details.
  
@@ -50, +47 @@

     }
  }
  }}}
- 
  Note that security objects are not regular versioned documents (that is, they are not under
MVCC rules). This is a design choice to speedup authorization checks (avoids traversing a
database's documents B-Tree).
  
  If both the names and roles fields of either the admins or readers properties are empty
arrays, it means the database has no admins or readers. Having no admins, only server admins
(with the reserved _admin role) are able to update design document and make other admin level
changes. Having no readers, any user can write regular documents (any non-design document)
and read documents from the database.
@@ -64, +60 @@

  authentication_db = _users
  require_valid_user = false
  }}}
- 
  The ''require_valid_user'' configuration parameter shown above causes CouchDB to have the
following behaviour:
  
-   1. No server admins are configured:
+  1. No server admins are configured:
-     1. ''require_valid_user'' is set to false: the request will be validated (by the handler
''{couch_httpd_auth, default_authentication_handler}'') as if it originated from a server
admin, but only if the handler did not found any authentication credentials in the user's
HTTP request message
+   1. ''require_valid_user'' is set to false: the request will be validated (by the handler
''{couch_httpd_auth, default_authentication_handler}'') as if it originated from a server
admin, but only if the handler did not found any authentication credentials in the user's
HTTP request message
-     1. ''require_valid_user'' is set to true: if none of the configured authentication handlers
succeeds, an HTTP message with error code 401 (unauthorized) will be sent back to the requester
+   1. ''require_valid_user'' is set to true: if none of the configured authentication handlers
succeeds, an HTTP message with error code 401 (unauthorized) will be sent back to the requester
  
-   1. There are one or more server admins configured:
+  1. There are one or more server admins configured:
-     1. ''require_valid_user'' is set to false: the request will be validated as "anonymous"
(unnamed user, no roles)
+   1. ''require_valid_user'' is set to false: the request will be validated as "anonymous"
(unnamed user, no roles)
-     1. ''require_valid_user'' is set to true: if none of the configured authentication handlers
succeeds, an HTTP message with error code 401 (unauthorized) will be sent back to the requester
+   1. ''require_valid_user'' is set to true: if none of the configured authentication handlers
succeeds, an HTTP message with error code 401 (unauthorized) will be sent back to the requester
  
  Currently the documents in the authentication database can only have the type attribute
set to "user". Such documents have the following structure:
  
@@ -87, +82 @@

    "salt"         : "4e170ffeb6f34daecfd814dfb4001a73"
  }
  }}}
- 
  The "_id" attribute value must be prefixed with the string "org.couchdb.user:" and the rest
must match the value of the attribute "name". The roles attribute must be an array of roles
(and each role is a string). The "password_sha" attribute is an hexadecimal representation
of the SHA-1 hash computed over a string that matches the user password concatenated with
a salt (ideally a random string). The salt attribute is the hexadecimal representation of
the salt used to generate the user's password hash.
  
  '''Note:''' please see "Generating password_sha" below for more about the SHA-1 hash.
  
  Some rules regarding user documents:
  
-   * when created by a non server admin user, the "roles" attribute must be an empty array
+  * when created by a non server admin user, the "roles" attribute must be an empty array
  
-   * a non server admin user can only update his own user document
+  * a non server admin user can only update his own user document
  
-   * when updated by a non server admin user, the "roles" attribute must remain unchanged
+  * when updated by a non server admin user, the "roles" attribute must remain unchanged
  
-   * role names can not start with an underscore - such role names are used for system roles
+  * role names can not start with an underscore - such role names are used for system roles
  
-   * user names can not start with an underscore - such user names are reserved for internal
system operations
+  * user names can not start with an underscore - such user names are reserved for internal
system operations
  
  Finally, server admins can create user documents that represent themselves. This is useful
if server admins (which always have the role "_admin") want to have other roles (application
specific roles). User documents that represent server admins do not need to have the "password_sha"
and "salt" attributes defined - their authentication credentials are stored in the .ini configuration
files.
  
  All these rules regarding authentication database documents are enforced by the validate
document update function stored in the design document with ID "_design/_auth" found in the
authentication database (it is automatically created by CouchDB).
  
  === Generating password_sha ===
- 
- `password_sha` can be generated a number of different ways.  Open``SSL's `sha` and `sha1`
functions are not compatible.  Below are some methods that work:
+ `password_sha` can be generated a number of different ways.  OpenSSL's `sha` and `sha1`
functions are not compatible.  Below are some methods that work:
  
  Erlang
  
@@ -125, +118 @@

  1> couch_util:to_hex(crypto:sha("foobar")).
  "8843d7f92416211de9ebb963ff4ce28125932878"
  }}}
- 
  Ruby
  
  {{{
@@ -134, +126 @@

  irb(main):002:0> Digest::SHA1.hexdigest 'foobar'
  => "8843d7f92416211de9ebb963ff4ce28125932878"
  }}}
- 
  Python
  
  {{{
@@ -146, +137 @@

  >>> h.hexdigest()
  '8843d7f92416211de9ebb963ff4ce28125932878'
  }}}
- 
  sha1.js implementation (from [[https://github.com/apache/couchdb/blob/trunk/share/www/script/sha1.js|CouchDB]])
  
  {{{
  hex_sha1(foobar);
  }}}
+ ==== Salt and Password Generator ====
+ This Perl script expects a password on STDIN or as its first parameter, and an optional
salt as its second parameter. If no salt is provided, a random one will be selected.
  
+ The salt and password_sha are printed on STDOUT.
+ 
+ {{{#!/usr/bin/env perl
+ # Usage: couchdb_password [password [salt]]  or provide password on STDIN.
+ 
+ use Digest::SHA1 qw(sha1);
+ 
+ my $password;
+ 
+ if(@ARGV) {
+   $password = shift;
+ } else {
+   $password = <>;
+   chomp $password;
+ }
+ 
+ my $salt;
+ 
+ if(@ARGV) {
+   my $unsalted = shift;
+   $salt = pack("H*",$unsalted);
+ } else {
+   # Get some bytes from random
+   open(my $urandom, '<', '/dev/urandom') or die $!;
+   binmode($urandom);
+   my $random_bytes;
+   read($urandom,$random_bytes,16) == 16 or die $!;
+   close($urandom) or die $!;
+ 
+   $salt = unpack('H*',sha1($random_bytes));
+ }
+ 
+ print "salt = $salt\n";
+ 
+ my $password_sha = sha1($password,$salt);
+ print "password_sha = ".unpack('H*',$password_sha)."\n";
+ }}}
  == Document Update Validation ==
- 
  See [[Document_Update_Validation]].
  

Mime
View raw message