Uploaded image for project: 'CouchDB'
  1. CouchDB
  2. COUCHDB-2221

malformed iterations field in _users doc causes authentication hang

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Database Core
    • Labels:
      None

      Description

      Create a user account with the following details:

      { "_id":"org.couchdb.user:test-user", "name":"test-user", "password":"this is a test" "roles":[], "type":"user" }

      CouchDB will PBKDF2-ify the password in the _users doc. So far so good.

      Then, try this:

      ubuntu@ip-172-31-35-228:~$ curl http://localhost:5984/_users/org.couchdb.user:test-user -u "test-user:this is not the correct password" -vvv

      • About to connect() to localhost port 5984 (#0)
      • Trying 127.0.0.1... connected
      • Server auth using Basic with user 'test-user'
        > GET /_users/org.couchdb.user:test-user HTTP/1.1
        > Authorization: Basic dGVzdHVzZXI6dGhpcyBpcyBub3QgdGhlIGNvcnJlY3QgcGFzc3dvcmQ=
        > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
        > Host: localhost:15984
        > Accept: /
        >

      And then it hangs indefinitely.

      This does not happen when the user account uses password_sha. For example:

      ubuntu@ip-172-31-35-228:~$ curl http://localhost:15984/_users/org.couchdb.user:testuserasdf -u "testuserasdf:this is not the correct password" -vvv

      • About to connect() to localhost port 15984 (#0)
      • Trying 127.0.0.1... connected
      • Server auth using Basic with user 'testuserasdf'
        > GET /_users/org.couchdb.user:testuserasdf HTTP/1.1
        > Authorization: Basic dGVzdHVzZXJhc2RmOnRoaXMgaXMgbm90IHRoZSBjb3JyZWN0IHBhc3N3b3Jk
        > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
        > Host: localhost:15984
        > Accept: /
        >
        < HTTP/1.1 401 Unauthorized
        < Server: CouchDB/1.5.0 (Erlang OTP/R14B04)
        < Date: Sat, 05 Apr 2014 22:58:54 GMT
        < Content-Type: text/plain; charset=utf-8
        < Content-Length: 67
        < Cache-Control: must-revalidate
        < {"error":"unauthorized","reason":"Name or password is incorrect."}
      • Connection #0 to host localhost left intact
      • Closing connection #0

      This is a serious and urgent problem for npm.

      At the urging of many people in the CouchDB and Node.js community, we've been migrating users to pbkdf2 accounts. However, rather than quickly report authorization failures, it hangs indefinitely, and eventually our TLS terminator returns a 500 or our CDN returns a 503.

      Because the appropriate HTTP response code is not being returned, we cannot hope to properly handle the situation. It looks like the server has just fallen over. Already the user experience has started to get pretty awful.

      What's worse, I fear that this is a DOS exploit, because it ties up a connection for a very long time. The npm registry is somewhat insulated by our CDN, but any CouchDB using pbkdf2 password storage is vulnerable.

        Activity

        Hide
        wohali Joan Touzet added a comment -

        isaacs and I are working this out in IRC. Right now we are unable to reproduce on OSX, Windows, or my local Debian install. More information coming.

        Show
        wohali Joan Touzet added a comment - isaacs and I are working this out in IRC. Right now we are unable to reproduce on OSX, Windows, or my local Debian install. More information coming.
        Hide
        wohali Joan Touzet added a comment -

        Isaac states that he can reproduce this in his AWS EC2 instance running R15B01 and in his SmartOS Joyent Public Cloud instance running R16B

        Isaac also confirms that this only occurs when the user is set to encrypt the password with pbkdf2.

        I am working to try and reproduce this on Ubuntu 12.04.1 LTS (precise) and will update shortly.

        Show
        wohali Joan Touzet added a comment - Isaac states that he can reproduce this in his AWS EC2 instance running R15B01 and in his SmartOS Joyent Public Cloud instance running R16B Isaac also confirms that this only occurs when the user is set to encrypt the password with pbkdf2. I am working to try and reproduce this on Ubuntu 12.04.1 LTS (precise) and will update shortly.
        Hide
        isaacs Isaac Z. Schlueter added a comment -

        Seems like this is most likely related to the length of the "salt" string.

        https://gist.github.com/isaacs/9999552

        Reproducible.

        Show
        isaacs Isaac Z. Schlueter added a comment - Seems like this is most likely related to the length of the "salt" string. https://gist.github.com/isaacs/9999552 Reproducible.
        Hide
        isaacs Isaac Z. Schlueter added a comment -

        Probably not strictly length of the salt string. Resetting the password (and thus getting a new 60-char salt) causes it to work in most cases.

        Show
        isaacs Isaac Z. Schlueter added a comment - Probably not strictly length of the salt string. Resetting the password (and thus getting a new 60-char salt) causes it to work in most cases.
        Hide
        isaacs Isaac Z. Schlueter added a comment -

        This is also most likely the reason why our write master has had 16 pegged CPUs so much of the time. Check out what happens when it's reproduced: http://cl.ly/image/1y0z3Z3c3O3D

        Also, reproducible if you use a 30-char salt, so the length is definitely not the issue.

        Eg:

        $ curl -X PUT http://localhost:5984/_users/org.couchdb.user:test5 -d '

        {"_id":"org.couchdb.user:test5","name":"test5","type":"user","password_scheme":"pbkdf2","derived_key":"abb04de17fe76742602e71f5dc37ef04253e623a","salt":"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa","iterations":"10","type":"user","roles":[]}

        ' -H content-type:application/json

        $ curl http://localhost:5984/_users/org.couchdb.user:test5 -u test5:testpass
        [hangs]

        Show
        isaacs Isaac Z. Schlueter added a comment - This is also most likely the reason why our write master has had 16 pegged CPUs so much of the time. Check out what happens when it's reproduced: http://cl.ly/image/1y0z3Z3c3O3D Also, reproducible if you use a 30-char salt, so the length is definitely not the issue. Eg: $ curl -X PUT http://localhost:5984/_users/org.couchdb.user:test5 -d ' {"_id":"org.couchdb.user:test5","name":"test5","type":"user","password_scheme":"pbkdf2","derived_key":"abb04de17fe76742602e71f5dc37ef04253e623a","salt":"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa","iterations":"10","type":"user","roles":[]} ' -H content-type:application/json $ curl http://localhost:5984/_users/org.couchdb.user:test5 -u test5:testpass [hangs]
        Hide
        isaacs Isaac Z. Schlueter added a comment -

        Definitely not related to the specifics of the salt. Perhaps the order of the keys in the object is to blame?

        With the user docs below, test8 hangs, but test9 works fine.

        $ curl -X PUT http://localhost:5984/_users/org.couchdb.user:test8 -d '

        {"_id":"org.couchdb.user:test8","name":"test8","type":"user","password_scheme":"pbkdf2","derived_key":"01bd544b37b1d274b5a199ec38a65d2ed498b02a","salt":"200a66d70dedb92bc66af9a3863d8491","iterations":"10","type":"user","roles":[]}

        ' -H content-type:application/json

        {"ok":true,"id":"org.couchdb.user:test8","rev":"1-f097401bb8991cf77fca7be6c93f5d61"}

        $ curl -X PUT http://localhost:5984/_users/org.couchdb.user:test9 -d '

        {"_id":"org.couchdb.user:test9","name":"test9","type":"user","roles":[],"iterations":10,"password_scheme":"pbkdf2","derived_key":"01bd544b37b1d274b5a199ec38a65d2ed498b02a","salt":"200a66d70dedb92bc66af9a3863d8491"}

        ' -H content-type:application/json

        {"ok":true,"id":"org.couchdb.user:test9","rev":"1-b0d0179df827b6038212651a6aa3429c"}
        Show
        isaacs Isaac Z. Schlueter added a comment - Definitely not related to the specifics of the salt. Perhaps the order of the keys in the object is to blame? With the user docs below, test8 hangs, but test9 works fine. $ curl -X PUT http://localhost:5984/_users/org.couchdb.user:test8 -d ' {"_id":"org.couchdb.user:test8","name":"test8","type":"user","password_scheme":"pbkdf2","derived_key":"01bd544b37b1d274b5a199ec38a65d2ed498b02a","salt":"200a66d70dedb92bc66af9a3863d8491","iterations":"10","type":"user","roles":[]} ' -H content-type:application/json {"ok":true,"id":"org.couchdb.user:test8","rev":"1-f097401bb8991cf77fca7be6c93f5d61"} $ curl -X PUT http://localhost:5984/_users/org.couchdb.user:test9 -d ' {"_id":"org.couchdb.user:test9","name":"test9","type":"user","roles":[],"iterations":10,"password_scheme":"pbkdf2","derived_key":"01bd544b37b1d274b5a199ec38a65d2ed498b02a","salt":"200a66d70dedb92bc66af9a3863d8491"} ' -H content-type:application/json {"ok":true,"id":"org.couchdb.user:test9","rev":"1-b0d0179df827b6038212651a6aa3429c"}
        Hide
        isaacs Isaac Z. Schlueter added a comment -

        Seems like this happens if the "iterations" field is a string rather than a number.

        $ curl -X PUT http://localhost:5984/_users/org.couchdb.user:test15 -d '

        {"_id":"org.couchdb.user:test15","name":"test15","type":"user","roles":[],"password_scheme":"pbkdf2","iterations":"10","derived_key":"01bd544b37b1d274b5a199ec38a65d2ed498b02a","salt":"200a66d70dedb92bc66af9a3863d8491"}

        ' -H content-type:application/json

        {"ok":true,"id":"org.couchdb.user:test15","rev":"1-b16557212dd9f8f5d2f414911c83de50"}

        $ curl -X PUT http://localhost:5984/_users/org.couchdb.user:test13 -d '

        {"_id":"org.couchdb.user:test13","name":"test13","type":"user","roles":[],"password_scheme":"pbkdf2","iterations":10,"derived_key":"01bd544b37b1d274b5a199ec38a65d2ed498b02a","salt":"200a66d70dedb92bc66af9a3863d8491"}

        ' -H content-type:application/json

        {"ok":true,"id":"org.couchdb.user:test13","rev":"1-124471b3297889296f601011b64e6355"}

        Then test13 works fine, but test15 hangs.

        Show
        isaacs Isaac Z. Schlueter added a comment - Seems like this happens if the "iterations" field is a string rather than a number. $ curl -X PUT http://localhost:5984/_users/org.couchdb.user:test15 -d ' {"_id":"org.couchdb.user:test15","name":"test15","type":"user","roles":[],"password_scheme":"pbkdf2","iterations":"10","derived_key":"01bd544b37b1d274b5a199ec38a65d2ed498b02a","salt":"200a66d70dedb92bc66af9a3863d8491"} ' -H content-type:application/json {"ok":true,"id":"org.couchdb.user:test15","rev":"1-b16557212dd9f8f5d2f414911c83de50"} $ curl -X PUT http://localhost:5984/_users/org.couchdb.user:test13 -d ' {"_id":"org.couchdb.user:test13","name":"test13","type":"user","roles":[],"password_scheme":"pbkdf2","iterations":10,"derived_key":"01bd544b37b1d274b5a199ec38a65d2ed498b02a","salt":"200a66d70dedb92bc66af9a3863d8491"} ' -H content-type:application/json {"ok":true,"id":"org.couchdb.user:test13","rev":"1-124471b3297889296f601011b64e6355"} Then test13 works fine, but test15 hangs.
        Hide
        wohali Joan Touzet added a comment - - edited

        Confirmed, the pid backtrace is as follows:

         [{status,runnable},
          {current_function,{crypto,max_bytes,0}},
          {current_stacktrace,
              [{crypto,max_bytes,0,[{file,"crypto.erl"},{line,669}]},
               {crypto,exor,2,[{file,"crypto.erl"},{line,533}]},
               {couch_passwords,pbkdf2,7,[{file,"couch_passwords.erl"},{line,90}]},
               {couch_passwords,pbkdf2,6,[{file,"couch_passwords.erl"},{line,74}]},
               {couch_passwords,pbkdf2,4,[{file,"couch_passwords.erl"},{line,65}]},
               {couch_passwords,pbkdf2,3,[{file,"couch_passwords.erl"},{line,54}]},
               {couch_httpd_auth,authenticate,2,
                   [{file,"couch_httpd_auth.erl"},{line,348}]},
               {couch_httpd_auth,default_authentication_handler,1,
                   [{file,"couch_httpd_auth.erl"},{line,71}]}]}],
        

        This is effectively an infinite loop: a string is always greater than an integer in Erlang.

        Two fixes recommended:

        1. _users validate_doc_update should force the iterations field to be an integer
        2. use couch_util:to_integer/1 in couch_httpd_auth,authenticate/2 at line 347 for the Iterations value anyway

        Working on a PR now.

        Show
        wohali Joan Touzet added a comment - - edited Confirmed, the pid backtrace is as follows: [{status,runnable}, {current_function,{crypto,max_bytes,0}}, {current_stacktrace, [{crypto,max_bytes,0,[{file,"crypto.erl"},{line,669}]}, {crypto,exor,2,[{file,"crypto.erl"},{line,533}]}, {couch_passwords,pbkdf2,7,[{file,"couch_passwords.erl"},{line,90}]}, {couch_passwords,pbkdf2,6,[{file,"couch_passwords.erl"},{line,74}]}, {couch_passwords,pbkdf2,4,[{file,"couch_passwords.erl"},{line,65}]}, {couch_passwords,pbkdf2,3,[{file,"couch_passwords.erl"},{line,54}]}, {couch_httpd_auth,authenticate,2, [{file,"couch_httpd_auth.erl"},{line,348}]}, {couch_httpd_auth,default_authentication_handler,1, [{file,"couch_httpd_auth.erl"},{line,71}]}]}], This is effectively an infinite loop: a string is always greater than an integer in Erlang. Two fixes recommended: _users validate_doc_update should force the iterations field to be an integer use couch_util:to_integer/1 in couch_httpd_auth,authenticate/2 at line 347 for the Iterations value anyway Working on a PR now.
        Hide
        wohali Joan Touzet added a comment -
        Show
        wohali Joan Touzet added a comment - https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=006d81965d9d09d3fe97a45c973198dc166dafda To fix this in 1.5.x, we also should cherry pick 98d0890.
        Hide
        kxepal Alexander Shorin added a comment -

        Hey Isaac Z. Schlueter,

        What's wrong with your validate_doc_update function? It already should protects your docs from having string value for iterations field.

        Show
        kxepal Alexander Shorin added a comment - Hey Isaac Z. Schlueter , What's wrong with your validate_doc_update function? It already should protects your docs from having string value for iterations field.
        Hide
        rnewson Robert Newson added a comment -

        hrm;

        if (newDoc.password_scheme === \"pbkdf2\") {
        if (typeof(newDoc.iterations) !== \"number\") {
        throw(

        {forbidden: \"iterations must be a number.\"}

        );
        }

        we inject validation for this.

        As for the fix, I'd rather fail better than tolerate invalid input, if possible.

        Show
        rnewson Robert Newson added a comment - hrm; if (newDoc.password_scheme === \"pbkdf2\") { if (typeof(newDoc.iterations) !== \"number\") { throw( {forbidden: \"iterations must be a number.\"} ); } we inject validation for this. As for the fix, I'd rather fail better than tolerate invalid input, if possible.
        Hide
        rnewson Robert Newson added a comment -

        Do we know how iterations became "10" in the docs? CouchDB shouldn't be doing that, replication shouldn't be either, so .... what did?

        Show
        rnewson Robert Newson added a comment - Do we know how iterations became "10" in the docs? CouchDB shouldn't be doing that, replication shouldn't be either, so .... what did?
        Hide
        wohali Joan Touzet added a comment -

        Alexander Shorin Robert Newson That function is not in 1.5.x, it's only in head. NPM runs 1.5.0. Thus, the request to backport.

        Without the validation function in there, any user using CouchDB prior to the unreleased 1.6.0 creating user docs thru futon can introduce this error.

        Show
        wohali Joan Touzet added a comment - Alexander Shorin Robert Newson That function is not in 1.5.x, it's only in head. NPM runs 1.5.0. Thus, the request to backport. Without the validation function in there, any user using CouchDB prior to the unreleased 1.6.0 creating user docs thru futon can introduce this error.
        Hide
        rnewson Robert Newson added a comment -

        Reading #couchdb backchannel, Isaac Z. Schlueter says he has a custom validate_doc_update function anyway, so the backport is unnecessary (there's no plan to do a 1.5.2 release afaik).

        My suggestion is to change the auth module to fail better on bad input or a full try/catch around the parsing of these functions, falling back to a sane default. The patch shown will only handle this kind of error ("10" instead of 10) and not others (if iterations was "hello" or [1,2,3] or true or {}).

        Show
        rnewson Robert Newson added a comment - Reading #couchdb backchannel, Isaac Z. Schlueter says he has a custom validate_doc_update function anyway, so the backport is unnecessary (there's no plan to do a 1.5.2 release afaik). My suggestion is to change the auth module to fail better on bad input or a full try/catch around the parsing of these functions, falling back to a sane default. The patch shown will only handle this kind of error ("10" instead of 10) and not others (if iterations was "hello" or [1,2,3] or true or {}).
        Hide
        rnewson Robert Newson added a comment -

        Clarifying topic to reflect the document is malformed. 1.6.0 will validate the types of all _user properties.

        Show
        rnewson Robert Newson added a comment - Clarifying topic to reflect the document is malformed. 1.6.0 will validate the types of all _user properties.
        Hide
        rnewson Robert Newson added a comment -

        For clarity, I don't think CouchDB should accept malformed user docs. If the field is malformed in any way we should either refuse to authenticate (send 401) or fallback to a sane, well-formed default in code. e.g;

        https://gist.github.com/rnewson/10008876

        Fixing this for one field is a step in the right direction but we should iterate a little to cover all the auth-related fields in _users docs and include generic functions for this. For example, we could write couch_util:get_int_value(Key, List, Default) with the defined behaviour that you get Default if there's no entry in the list or if the value associate with Key is not an integer. The function will throw an exception if Default is not an integer.

        The fundamental bug here is that the code continued on using a string when an int was required and, as @wohali notes, there's no int that sorts higher than a string. The minimum fix is a proper crash. I'm averse to adding error-handling code for specific examples of general problems.

        Show
        rnewson Robert Newson added a comment - For clarity, I don't think CouchDB should accept malformed user docs. If the field is malformed in any way we should either refuse to authenticate (send 401) or fallback to a sane, well-formed default in code. e.g; https://gist.github.com/rnewson/10008876 Fixing this for one field is a step in the right direction but we should iterate a little to cover all the auth-related fields in _users docs and include generic functions for this. For example, we could write couch_util:get_int_value(Key, List, Default) with the defined behaviour that you get Default if there's no entry in the list or if the value associate with Key is not an integer. The function will throw an exception if Default is not an integer. The fundamental bug here is that the code continued on using a string when an int was required and, as @wohali notes, there's no int that sorts higher than a string. The minimum fix is a proper crash. I'm averse to adding error-handling code for specific examples of general problems.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 887b42022430b565f82d941042712d43b61761e8 in couchdb's branch refs/heads/2221-bug-validate-auth-params from Robert Newson
        [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=887b420 ]

        Verify that auth-related properties are well-formed

        Passing unexpected values to auth fields can result in server
        issues. Notably, setting "iterations" to a string will cause an
        infinite loop as the comparison 'when Iteration > Iterations' will
        never evaluate to false.

        The latest validate_doc_update prevents user docs with this problem
        and administrators can deploy that check themselves (and only
        administrators can edit design documents).

        COUCHDB-2221

        Show
        jira-bot ASF subversion and git services added a comment - Commit 887b42022430b565f82d941042712d43b61761e8 in couchdb's branch refs/heads/2221-bug-validate-auth-params from Robert Newson [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=887b420 ] Verify that auth-related properties are well-formed Passing unexpected values to auth fields can result in server issues. Notably, setting "iterations" to a string will cause an infinite loop as the comparison 'when Iteration > Iterations' will never evaluate to false. The latest validate_doc_update prevents user docs with this problem and administrators can deploy that check themselves (and only administrators can edit design documents). COUCHDB-2221
        Hide
        rnewson Robert Newson added a comment -

        I pondered this some more and it bothers me that users have free reign over how many iterations they use. The server administrator should be in charge here. Thus I propose https://gist.github.com/rnewson/6f6cc38e9f5e9ac22e65 which will allow couchdb to reject (with a 403) any user doc using either a too weak or too strong iteration count, defaulting to generous bounds. The guard clause on verify_iterations also serves to prevent the infinite loop this ticket was raised about.

        Let's regroup Monday to decide what combination of this we want to go with and which release besides 1.6.x it might go in.

        Show
        rnewson Robert Newson added a comment - I pondered this some more and it bothers me that users have free reign over how many iterations they use. The server administrator should be in charge here. Thus I propose https://gist.github.com/rnewson/6f6cc38e9f5e9ac22e65 which will allow couchdb to reject (with a 403) any user doc using either a too weak or too strong iteration count, defaulting to generous bounds. The guard clause on verify_iterations also serves to prevent the infinite loop this ticket was raised about. Let's regroup Monday to decide what combination of this we want to go with and which release besides 1.6.x it might go in.
        Hide
        wohali Joan Touzet added a comment - - edited

        +1 on the 2 patches, they preserves the spirit of my patch (don't go into an infinite loop) and sets reasonable bounds thereon. We could also apply some guards on allowed schemes to prevent simple authentication when we're ready to make that change.

        Show
        wohali Joan Touzet added a comment - - edited +1 on the 2 patches, they preserves the spirit of my patch (don't go into an infinite loop) and sets reasonable bounds thereon. We could also apply some guards on allowed schemes to prevent simple authentication when we're ready to make that change.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 181a32c15bcf85b767a69f5645a4a8a16fd1189a in couchdb's branch refs/heads/2221-bug-validate-auth-params from Robert Newson
        [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=181a32c ]

        Verify that auth-related properties are well-formed

        Passing unexpected values to auth fields can result in server
        issues. Notably, setting "iterations" to a string will cause an
        infinite loop as the comparison 'when Iteration > Iterations' will
        never evaluate to false.

        The latest validate_doc_update prevents user docs with this problem
        and administrators can deploy that check themselves (and only
        administrators can edit design documents).

        A server administrator can also insist on lower and upper bounds for
        iteration count to reject weakly protected passwords and
        resource-hungry passwords respectively.

        COUCHDB-2221

        Show
        jira-bot ASF subversion and git services added a comment - Commit 181a32c15bcf85b767a69f5645a4a8a16fd1189a in couchdb's branch refs/heads/2221-bug-validate-auth-params from Robert Newson [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=181a32c ] Verify that auth-related properties are well-formed Passing unexpected values to auth fields can result in server issues. Notably, setting "iterations" to a string will cause an infinite loop as the comparison 'when Iteration > Iterations' will never evaluate to false. The latest validate_doc_update prevents user docs with this problem and administrators can deploy that check themselves (and only administrators can edit design documents). A server administrator can also insist on lower and upper bounds for iteration count to reject weakly protected passwords and resource-hungry passwords respectively. COUCHDB-2221
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit dbe769c604e5f1e000594336f8c4546bf9e3fd5a in couchdb's branch refs/heads/2221-bug-validate-auth-params from Robert Newson
        [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=dbe769c ]

        Verify that auth-related properties are well-formed

        Passing unexpected values to auth fields can result in server
        issues. Notably, setting "iterations" to a string will cause an
        infinite loop as the comparison 'when Iteration > Iterations' will
        never evaluate to true.

        The latest validate_doc_update prevents user docs with this problem
        and administrators can deploy that check themselves (and only
        administrators can edit design documents).

        A server administrator can also insist on lower and upper bounds for
        iteration count to reject weakly protected passwords and
        resource-hungry passwords respectively.

        COUCHDB-2221

        Show
        jira-bot ASF subversion and git services added a comment - Commit dbe769c604e5f1e000594336f8c4546bf9e3fd5a in couchdb's branch refs/heads/2221-bug-validate-auth-params from Robert Newson [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=dbe769c ] Verify that auth-related properties are well-formed Passing unexpected values to auth fields can result in server issues. Notably, setting "iterations" to a string will cause an infinite loop as the comparison 'when Iteration > Iterations' will never evaluate to true. The latest validate_doc_update prevents user docs with this problem and administrators can deploy that check themselves (and only administrators can edit design documents). A server administrator can also insist on lower and upper bounds for iteration count to reject weakly protected passwords and resource-hungry passwords respectively. COUCHDB-2221
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit dbe769c604e5f1e000594336f8c4546bf9e3fd5a in couchdb's branch refs/heads/master from Robert Newson
        [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=dbe769c ]

        Verify that auth-related properties are well-formed

        Passing unexpected values to auth fields can result in server
        issues. Notably, setting "iterations" to a string will cause an
        infinite loop as the comparison 'when Iteration > Iterations' will
        never evaluate to true.

        The latest validate_doc_update prevents user docs with this problem
        and administrators can deploy that check themselves (and only
        administrators can edit design documents).

        A server administrator can also insist on lower and upper bounds for
        iteration count to reject weakly protected passwords and
        resource-hungry passwords respectively.

        COUCHDB-2221

        Show
        jira-bot ASF subversion and git services added a comment - Commit dbe769c604e5f1e000594336f8c4546bf9e3fd5a in couchdb's branch refs/heads/master from Robert Newson [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=dbe769c ] Verify that auth-related properties are well-formed Passing unexpected values to auth fields can result in server issues. Notably, setting "iterations" to a string will cause an infinite loop as the comparison 'when Iteration > Iterations' will never evaluate to true. The latest validate_doc_update prevents user docs with this problem and administrators can deploy that check themselves (and only administrators can edit design documents). A server administrator can also insist on lower and upper bounds for iteration count to reject weakly protected passwords and resource-hungry passwords respectively. COUCHDB-2221
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit aab36a8aa39994cf73d72875b981d324ed95cb1f in couchdb-couch's branch refs/heads/import-master-tmp from Robert Newson
        [ https://git-wip-us.apache.org/repos/asf?p=couchdb-couch.git;h=aab36a8 ]

        Verify that auth-related properties are well-formed

        Passing unexpected values to auth fields can result in server
        issues. Notably, setting "iterations" to a string will cause an
        infinite loop as the comparison 'when Iteration > Iterations' will
        never evaluate to true.

        The latest validate_doc_update prevents user docs with this problem
        and administrators can deploy that check themselves (and only
        administrators can edit design documents).

        A server administrator can also insist on lower and upper bounds for
        iteration count to reject weakly protected passwords and
        resource-hungry passwords respectively.

        COUCHDB-2221

        Show
        jira-bot ASF subversion and git services added a comment - Commit aab36a8aa39994cf73d72875b981d324ed95cb1f in couchdb-couch's branch refs/heads/import-master-tmp from Robert Newson [ https://git-wip-us.apache.org/repos/asf?p=couchdb-couch.git;h=aab36a8 ] Verify that auth-related properties are well-formed Passing unexpected values to auth fields can result in server issues. Notably, setting "iterations" to a string will cause an infinite loop as the comparison 'when Iteration > Iterations' will never evaluate to true. The latest validate_doc_update prevents user docs with this problem and administrators can deploy that check themselves (and only administrators can edit design documents). A server administrator can also insist on lower and upper bounds for iteration count to reject weakly protected passwords and resource-hungry passwords respectively. COUCHDB-2221
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 7439833ea51ac1436f341c7aab6e8de1fe4a2a18 in couchdb's branch refs/heads/1843-feature-bigcouch from Robert Newson
        [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=7439833 ]

        Verify that auth-related properties are well-formed

        Passing unexpected values to auth fields can result in server
        issues. Notably, setting "iterations" to a string will cause an
        infinite loop as the comparison 'when Iteration > Iterations' will
        never evaluate to true.

        The latest validate_doc_update prevents user docs with this problem
        and administrators can deploy that check themselves (and only
        administrators can edit design documents).

        A server administrator can also insist on lower and upper bounds for
        iteration count to reject weakly protected passwords and
        resource-hungry passwords respectively.

        COUCHDB-2221

        Show
        jira-bot ASF subversion and git services added a comment - Commit 7439833ea51ac1436f341c7aab6e8de1fe4a2a18 in couchdb's branch refs/heads/1843-feature-bigcouch from Robert Newson [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=7439833 ] Verify that auth-related properties are well-formed Passing unexpected values to auth fields can result in server issues. Notably, setting "iterations" to a string will cause an infinite loop as the comparison 'when Iteration > Iterations' will never evaluate to true. The latest validate_doc_update prevents user docs with this problem and administrators can deploy that check themselves (and only administrators can edit design documents). A server administrator can also insist on lower and upper bounds for iteration count to reject weakly protected passwords and resource-hungry passwords respectively. COUCHDB-2221

          People

          • Assignee:
            wohali Joan Touzet
            Reporter:
            isaacs Isaac Z. Schlueter
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development