[Couchdb Wiki] Update of "Security_Features_Overview" by JanLehnardt

[Apache Wiki <wi...@apache.org>]

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