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 JanLehnardt
Date Tue, 03 Jan 2012 20:58:26 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 JanLehnardt:
http://wiki.apache.org/couchdb/Security_Features_Overview?action=diff&rev1=31&rev2=32

Comment:
update for >= 1.2.0 system db security

    "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.
+ '''Note:''' If you are using CouchDB versions 1.1.x or earlier, please see "Generating password_sha"
below for more about the SHA-1 hash.
+ 
+ Since CouchDB 1.2.0, the `password_sha` and `salt` fields are automatically created when
a `password` field is present in the user document. When the user document is written, CouchDB
checks for the existence of the `password` field and if it exists, it will generate a salt,
hash the value of the `password field and hash the concatenation of the password hash and
the salt. It then writes the resulting password into the `password_sha` field and the salt
into the `salt` field. The `password` field is removed.
+ 
+ This has the following implications: Clients no longer have to calculate the password salt
and hash manually. Yay.
+ 
+ In addition, the `_users` database is now treated different from other databases:
+ 
+  * An anonymous user can only create a new document.
+ 
+  * An authenticated user can only update their own document.
+ 
+  * A server or database admin can access and update all documents.
+ 
+  * Only server or database admins can create design documents and access views and `_all_docs`
and `_changes`.
  
  Some rules regarding user documents:
  
@@ -107, +122 @@

  
  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).
+ 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) and by special system database
hooks inside CouchDB.
  
- === Generating password_sha ===
+ === Generating password_sha (only applicable for 1.1.x and earlier)===
  `password_sha` can be generated a number of different ways.  Below are some methods that
work:
  
  OpenSSL command line tool

Mime
View raw message