Capella cluster query access username and password security

Couchbase Capella
1

What is the correct security approach to query data using the c++ sdk from a capella cluster?

I am working on an app that may be distributed to many users. How do I safely store the username and password for querying the database?

Currently I have the Public Connection string and Cluster Access Credentials and I am able to connect and make a query just like in the C++ minimal example.

static constexpr auto connection_string{ "MY PUBLIC CONNECTION STRING" };
static constexpr auto username{ "MY USERNAME" };
static constexpr auto password{ "MY PASSWORD" };
static constexpr auto bucket_name{ "default" };
static constexpr auto scope_name{ couchbase::scope::default_name };
static constexpr auto collection_name{ couchbase::collection::default_name };

int
main()
{
  couchbase::logger::initialize_console_logger();
  couchbase::logger::set_level(couchbase::logger::log_level::trace);

  auto options = couchbase::cluster_options(username, password);
  options.apply_profile("wan_development");
  auto [connect_err, cluster] = couchbase::cluster::connect(connection_string, options).get();
.
.
.

However this clearly stores the username and password in plain text. What would be the correct approach in an app so the credentials are secure?

I have seen examples using Java keystore but this is just as confusing since first I would have to write to the keystore and again require the information in plain text in the code.

Thank you

2

Secure password storage is not specific to Couchbase. In Java, passwords can be stored securely in a Java keystore. There should be an analogous mechanism in C++. You might find an answer and examples on stackoverflow.

3

Thank you for such a quick reply :slight_smile:

As far as I understand I would not create a new username and password for each user right? I would have only a single set of Cluster Access Credentials used by all the app users.

If that’s the case I have seen a lot of example on how to use secure credential storage. However I don’t understand how to achieve the first step which is saving the Cluster Access Credentials to the secure storage without an overly complex system.

I am using Flutter for the UI but I think the language does not matter. I see a lot of examples like this

SecureStorage storage = SecureStorage();  
await storage.setAccessToken("mySecretToken123");
.
.
.
String? token = await storage.getAccessToken();  
log("Retrieved token: $token");

This is great since there is a way to store the information securely. However it still requires a call to store the information in the first place and that contains the credentials in plain text.

One way I can see it working is having another endpoint with a rest api that provides an encrypted version of the username and password somehow encrypted with the access token of the user. Then on the user device it is decrypted and added to the secure storage.

This seems overly complicated, is there a standard way to achieve secure credential storage without a plain text version of the credentials saved in the app? Does couchbase have a recommended approach?

Cheers

4

Use.one of those. Use whatever method the samples use to store the credentials. Perhaps manually.

If you start building a rest api that will supply the username/password, then.that api will need a username password, which would need to be stored securely… you see the problem.

5

Is there another scheme for secure credential transfer except having the credentials in plain text in some form?

My current thinking is using AWS Cognito to authenticate a user, this means I can get a unique user ID. Then have a rest API where the user sends a request and their unique ID. The reply contains encrypted credentials. User’s device decrypts them using user information as a key. After that I can store it in secure storage as all the examples.

This way the plain text is never available. I just assumed something like this is a common problem and that couchbase would provide APIs or another way to handle this.

6