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
