Home
last modified time | relevance | path

Searched +hist:0 +hist:cf47471 (Results 1 - 3 of 3) sorted by relevance

/Couchbase_C_Client_v3.0/cmake/Modules/
H A DGetPlatformCCInfo.cmakediff 0cf47471 Thu Oct 23 22:29:05 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Cmake: General improvements:

Fix up rpath settings:

CMake is typically used for developer builds; and as such, we should
make an attempt to have our own libraries and tools _not_ pick up system
libraries, unless we are a system install. This mimics existing
autotools behavior.

Silence CMP0026 warning on Windows

This "old" behavior here is intended, because the `LOCATION` property
can give us the name of the install path before the project has been
generated, allowing us to transform their names into proper PDB paths to
include within the final distribution.

Add package name for VC12 (VS 2013)

We don't build these packages officially yet, but it still makes it
nicer.

Use homebrew OpenSSL if available
The default OS X OpenSSL spams us with deprecation warnings; we'd be
better off using Homebrew's version.

Change-Id: I99af9f8e9b94f77e8f16cba80481645a30564f12
Reviewed-on: http://review.couchbase.org/42443
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0cf47471 Thu Oct 23 22:29:05 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Cmake: General improvements:

Fix up rpath settings:

CMake is typically used for developer builds; and as such, we should
make an attempt to have our own libraries and tools _not_ pick up system
libraries, unless we are a system install. This mimics existing
autotools behavior.

Silence CMP0026 warning on Windows

This "old" behavior here is intended, because the `LOCATION` property
can give us the name of the install path before the project has been
generated, allowing us to transform their names into proper PDB paths to
include within the final distribution.

Add package name for VC12 (VS 2013)

We don't build these packages officially yet, but it still makes it
nicer.

Use homebrew OpenSSL if available
The default OS X OpenSSL spams us with deprecation warnings; we'd be
better off using Homebrew's version.

Change-Id: I99af9f8e9b94f77e8f16cba80481645a30564f12
Reviewed-on: http://review.couchbase.org/42443
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
/Couchbase_C_Client_v3.0/src/ssl/
H A DCMakeLists.txtdiff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0cf47471 Thu Oct 23 22:29:05 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Cmake: General improvements:

Fix up rpath settings:

CMake is typically used for developer builds; and as such, we should
make an attempt to have our own libraries and tools _not_ pick up system
libraries, unless we are a system install. This mimics existing
autotools behavior.

Silence CMP0026 warning on Windows

This "old" behavior here is intended, because the `LOCATION` property
can give us the name of the install path before the project has been
generated, allowing us to transform their names into proper PDB paths to
include within the final distribution.

Add package name for VC12 (VS 2013)

We don't build these packages officially yet, but it still makes it
nicer.

Use homebrew OpenSSL if available
The default OS X OpenSSL spams us with deprecation warnings; we'd be
better off using Homebrew's version.

Change-Id: I99af9f8e9b94f77e8f16cba80481645a30564f12
Reviewed-on: http://review.couchbase.org/42443
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0cf47471 Thu Oct 23 22:29:05 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Cmake: General improvements:

Fix up rpath settings:

CMake is typically used for developer builds; and as such, we should
make an attempt to have our own libraries and tools _not_ pick up system
libraries, unless we are a system install. This mimics existing
autotools behavior.

Silence CMP0026 warning on Windows

This "old" behavior here is intended, because the `LOCATION` property
can give us the name of the install path before the project has been
generated, allowing us to transform their names into proper PDB paths to
include within the final distribution.

Add package name for VC12 (VS 2013)

We don't build these packages officially yet, but it still makes it
nicer.

Use homebrew OpenSSL if available
The default OS X OpenSSL spams us with deprecation warnings; we'd be
better off using Homebrew's version.

Change-Id: I99af9f8e9b94f77e8f16cba80481645a30564f12
Reviewed-on: http://review.couchbase.org/42443
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
/Couchbase_C_Client_v3.0/
H A DCMakeLists.txtdiff 31bd2afa Mon Jul 19 13:06:29 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.2.0

Change-Id: I0af9154473a5ba2fa30326475ff9b39ff27d3d94
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/157772
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff ed8b57e7 Wed Mar 03 07:31:38 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.1.0

Change-Id: I55e7e823d2a1ae4a47be86bc477f54b7b3b50e5a
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/147552
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0fb5c84a Thu Dec 20 10:55:05 UTC 2018 Sergey Avseyev <sergey.avseyev@gmail.com> Fix subdoc tests against real cluster

Change-Id: Ie79a789054290185793d82a06429e832c0110aab
Reviewed-on: http://review.couchbase.org/103083
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0dc3fd13 Fri Sep 15 08:41:11 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> Allow to defer rebalance for node failover

Change-Id: Ibe7e357d6de95ab0ffef9623dce608d8e5f58898
Reviewed-on: http://review.couchbase.org/83424
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 7c4988d0 Tue May 02 22:33:01 UTC 2017 Mark Nunberg <mnunberg@haskalah.org> CCBC-774: Update subdoc protocol for Spock

- This adds new doc-level flags, manifested as `LCB_CMDSUBDOC_F_` ...
- Allow full-doc get/set with `LCB_SDCMD_SET_FULLDOC` and
`LCB_SDCMD_GET_FULLDOC`
- Update to CouchbaseMock 1.5.0:
This also required a minor change to add a new attribute to the list of
known error map attributes. Otherwise it results in a parse failure.

Change-Id: I34f5c2a0180204133690d5a73638f85c78dfffa5
Reviewed-on: http://review.couchbase.org/77376
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support

This adds DNS SRV lookups for bootstrapping. This is provided in two
forms:

1. When there is only a single hostname with no port. This is called
implicit lookup
2. When the scheme `couchbase+dnssrv://` is used. This is an explicit
mode and is considered internal to the library.

In both cases the input hostname will be selected and attempted for a DNS SRV
query. If it succeeds, then the hosts use for the query will be
returned. If the query fails, implicit mode will continue, using the
hostname as a couchbase node, whereas explicit mode will fail. Explicit
mode is useful for debugging the dns srv feauture itself.

Currently support depends on either Windows (which works "out of the
box") and libbind/libresolv, which come bundled with glibc on both OS X
and Linux. This may fail to function on very ancient systems; in which
event these routines are stubbed out with no-op equivalents.

Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80
Reviewed-on: http://review.couchbase.org/46177
Reviewed-by: Brett Lawson <brett19@gmail.com>
Tested-by: buildbot <build@couchbase.com>

Completed in 52 milliseconds