Add cookie support to the replicator, then increase default PBKDF2 iterations

[wohali]

In a discussion with @rnewson today this point came up. We currently have an absurdly low number for default PBKDF2/bcrypt iterations/rounds (10) because the replicator does not use a session cookie.

If we can teach the replicator to use a session cookie, then we can crank up the default value such that POST /_session takes ~1000ms.

Expected Behaviour

• The replicator uses session cookies for authentication.
• Passwords are encrypted more strongly by default.

Current Behaviour

• The replicator supplies credentials on every request.
• Passwords are encrypted with only 10 rounds/iterations by default.

[wohali]

I'm told #1176 is sufficient for part of this.

We should make this default and make the necessary change to PBKDF2 iterations as well.

/cc @nickva

[wohali]

A concern about changing the defaults with this work is that, for <2.2.0 Couches replicating against a 2.2.0 Couch, replication will be very very slow. The workaround is to mediate the replication on the 2.2.0+ cluster, or to upgrade the remote node, whichever is easier. A last-ditch is to reduce the iterations/rounds on the 2.2.0+ cluster if necessary.

[janl]

How about we leave the default for 2.2.0, but mention the recommendation to increase rounds for situations where remotes are not <2.2.0 in the release notes. We can then decide at a later 2.x or 3.0 stage to up the default?

[nickva]

Thinking about the replicator session support. It is a configuration option now. It may make sense to switch to higher work factor and turn on session support at the same time. Maybe mention it in release notes for 2.2.0 that it is advisable to increase the work factor and switch on replication session support at the same time, then in the next release those will become the default?

[janl]

@nickva yeah this, +1.

I’ve started a documentation branch & PR that we can work on, so we can close this: apache/couchdb-documentation#292