Avoid weak master key

[gmourier]

Sub-discussion for #536

Description

Some time ago, @brunoocasali initiated a product discussion regarding the master key behavior to naturally guide users to a secured usage of Meilisearch.

Since the @meilisearch/cloud-team uses the master key for all operations, we have been unable to make the changes that initially seemed to help strengthen security.

However, we could consider introducing a more demanding format to avoid users setting a weak master key like 12345678 or masterKey to add more security guidance.

[curquiza]

I personally like this idea

• it's easy to implement
• it's a "free" security addition: forcing for 8 characters for example is not asking too much from the users, and is for their safety
• it's really breaking so we will not be able to do it after v1

[brunoocasali]

However, we could consider introducing a more demanding format to avoid users setting a weak master key like 12345678 or masterKey to add more security guidance.

So the idea is to follow a particular format or just to ensure a minimum hash size?

[brunoocasali]

I like the idea of having a particular format + minimum hash size.

We just want to ensure the users know clearly what they need to do to provide a good masterKey.

CC: @meilisearch/integration-team I know this would represent a very good amount of work for us, but in any case this brings more security to our software, not easy to decide but I would like your input here as well ;)

[curquiza]

I'm not sure this is a lot of work with our automation 🤔

[bidoubiwa]

I think asking for a longer master key is already a good security measure, a good balance between security and ease of setup. Are there other databases that are requiring password to be formatted like that?

[brunoocasali]

Agreed, but besides this point, we also have to think about how the user will face this problem and how they will solve the problem when it comes.

For example, will they have to create this token by themselves? Or will we provide a CLI option to generate one for them? If they try their own-generated token, which error and how will they understand the problem, Meilisearch will start anyway?

I think this is something it will seriously impact the first contact users have with us...

[gmourier]

Are there other databases that are requiring password to be formatted like that?

Not to my knowledge but it's something that is done by database operators for sure when exposing it. e.g https://kb.iu.edu/d/aphg

Although this can be thought out and done by experienced users by hand, the idea here is to ensure that a beginner can expose a Meilisearch endpoint on the public web under optimal security conditions.

Enforcing a more secure format for the master key will only solve some flaws.

We have seen users exposing the master key on the frontend. Solving that question from the engine side has been delayed due to the fact that the cloud-team currently uses the master-key to make every call on a Meilisearch instance. When they will look at the API key management UX, we must take that opportunity to consider fixing this flaw. Signal 📡 to @davelarkan.

If the master key is not exposed, having a more secure format protects the master key from being brute-forced by a malicious attempt.

[gmourier]

I would like to see this considered for v1.0

It means preventing users from using what we could consider a weak master key and guiding them most efficiently not to tarnish their experience, as @brunoocasali mentioned.

If you have solution proposals, we can start discussing them here.

For now, @brunoocasali proposed to expect a particular format + a minimum hash size.

[dureuill]

Hey @gmourier, apologies for the delay in responding to this, I'm still unsure of the broader security context of API keys (such as the attacker model and guaranteed properties).

I think I generally like @brunoocasali's solution, I can think of several pieces of software with a similar behavior:

• Jupyter Notebook generates a token to use in URLs for authentication on each startup. Because it is done by default, it can be a bit confusing and aggravating to unsuspecting users in a context where security is not felt as necessary. So even though it wasn't a proposal I like the fact that we can currently use meilisearch in "dev mode" without a master key at all.
• The Rocket web framework requires a secret key in release mode but generates it in debug mode. It also specifies the accepted format which I think would be reasonable for us too.

If we do go with @brunoocasali's route, it would be great to advertise the --generate-master-key in case the software is run without a master key.

[brunoocasali]

This is related to the central issue: meilisearch/meilisearch-dotnet#363 (comment)

[dureuill]

Thank you for the additional context, from there I can gather we'd need at least 16 bytes for the key... Do we know if we have other known constraints on the key's format? I think it is OK to impose constraints on the keys if we are providing a way to generate them.

Thinking more about key generation, I wonder if we should provide the feature itself (in the form of a flag like discussed), or if we could limit ourselves to outputting commands for users to execute on their machine, freeing us of the burden of providing cryptographically secure key generation. What do you think?

[brunoocasali]

What do you mean by outputting commands for users to execute on their machine? Like accessing some system library to generate the key?

[dureuill]

No I was thinking giving the command lines for the user to execute, much like GitHub is doing with SSH keys: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key

But let's disregard this, we should be able to generate secure master keys using a cryptographically secure random number generator.

[gmourier]

Thanks, everyone; the proposed ideas seem to solve the weak master key issue. To clarify, here is where we are exploring this topic, it also raises some questions we want to consider.

Enforcing a minimum number of chars for the master key instead of a specific format (e.g. uuid-v4, sha256, etc)

A suggestion brought up by @dureuill during the engine weekly meeting;

We don't necessarily want to wait for a specific format. Asking for a minimum number of characters could be sufficient to guide users to a more secure master key without requiring a format that can be difficult to generate. (@dureuill, please correct me if it's unclear or does not relate to your suggestion).

WDYT?

---

How many minimum characters should Meilisearch expect for the master key to be valid?

• 8 was mentioned by @curquiza
• 16 was mentioned by @dureuill

IMO, if no particular format is requested other than the current one (The master key must be composed of valid utf-8 characters), 16 characters seem better. WDYT?

Do we want to enforce this behavior regardless of the environment (development/production)?

@irevoire pointed out that it can be frustrating to have this requirement in the development environment for speed and testing reasons. WDYT?

Knowing that instances are exposed to the public with the dev environment, personally, I would be for enforcing it in any case, even if it could be a bump in the DX (when choosing to use a master key in development env) for the sake of security.

Another issue I see with that is that some users may be frustrated to see that it's asked when going for production, aka exposing it to the public (if they change the env to production) -> They will be forced to change the master key and thus have to update every client because the API Keys are updated. IMO that's a super bump.

CLI error message to indicate that the master key is not secure enough

Note: This is a suggestion

Error: The provided master key `:givenMasterKey` is not strong enough. It must be composed of `:numberOfCharacters` minimum utf-8 characters.

Do we want to give an extra helper to the error message?

If yes, the chosen method should be indicated in the above error message.

• It can be a command the OS provides that generates a random string of utf-8 :numberOfCharacters.
• It can be a Meilisearch command that does this.

[dureuill]

Hey @juchom 👋

If I summarize these new options, these could be options D and E such that:

1. Missing master key:

Solution\Environment	Development	Production
Current status	Nothing	Error
A	Warn	Error
B	Warn	Error
C (unchanged from current status)	Nothing	Error
D	Autogenerate	Autogenerate
E	Use default master-key	Use default master-key

What's not really clear to me is ho Meilisearch should react in options D and E if the user overrides the default/autogenerated master key with a key that doesn't meet the size requirement. Should the default/autogenerated master key override the supplied key in that case? Should there be an error?

But you take the risk of a user misconfiguring Meilisearch and have a development instance exposed with the default key on internet.

I don't think we're willing to take that risk 😬

As for forcing a master key (even autogenerated) even in dev mode, I guess the tradeoff is that we'd lose the real convenience to be able to test meilisearch as a new user by sending requests without using a key at all.

Thank you for detailing these ideas, @juchom !

[juchom]

What's not really clear to me is ho Meilisearch should react in options D and E if the user overrides the default/autogenerated master key with a key that doesn't meet the size requirement.

If the key is not strong enough it is rejected and the original master key is not changed or if it is at the initialization of the server, the server does not start.

As for forcing a master key (even autogenerated) even in dev mode, I guess the tradeoff is that we'd lose the real convenience to be able to test meilisearch as a new user by sending requests without using a key at all.

Displaying the key like @brunoocasali showed earlier and having a good quick start guide should be fine I think. It's a bit painful for users the first time to deal with a key, but they will have to do it anyway for other cloud services and they will be aware of the importance of a master key.

[dureuill]

Thank you for the precisions! My understanding is that the development mode is dedicated to onboarding users in the simplest possible way, and the simplest way is to continue allowing no master key in this mode. While having great documentation is an invaluable asset, especially for those users who need to understand all requirements before jumping in, I think being able to use meilisearch for the first time without reading the documentation related to master keys is invaluable too.

I think I'll provide an implementation of solution B in the next weeks, as I'd really like how visible the warnings in development mode will be in practice. It should be noted that converting the warning into an error in the development mode, that is, switching to solution C, is not really costly implementation-wise, meaning we can probably switch from one solution to the other or even test both solutions in the lead-up to v1.

Many thanks to everyone involved in this discussion so far 🙌

[brunoocasali]

@dureuill, which kind of warning are you thinking about implementing?

Mentioning that, because I consider the current behavior a warning:

[dureuill]

Hey @brunoocasali, you can see what I mean in the associated PR: meilisearch/meilisearch#3274

I put a screenshot of each situation. I took the liberty to request a review from you for this PR so that you can tell me what you think of these warnings. Feel free to suggest changes!

[gmourier]

Hey everyone 👋

I'm locking that discussion since it will be released for v1

Please open a new discussion to share feedback or ask for a feature request.

Thank you all for your hard work 🙇‍♂️