[question] How to securely store secrets with conan?

[mneumei]

What is your question?

I am currently trying to securely store and pass credentials to conan. From what i found, no matter how you pass the credentials to conan remote login, they will always be stored in conan.db.

Is this understanding correct? And is there any way around this, to not store the cleartext credentials in the conan.db file?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @mneumei

Thanks for your question.

Conan do not store plaintext credentials in .conan.db DB, or anywhere else.

When Conan gets credentials (interactively in the terminal, or by env-vars, etc), it sends them to auth to the server, and it obtains from the server a JWT, and forget the credentials. It is only the JWT the thing that is stored in the conan.db database.
This JWT is also typically short-lived, like it is typical to be in the range of hours to some days, I think Artifactory default is 30 days.

This JWT is not stored in plain text, but base 64, but if further security is desired, the CONAN_LOGIN_ENCRYPTION_KEY env-var can also cypher (vignere cypher) the JWT too.

Please let us know if this helps.

[mneumei]

With which version was this introduced?

[memsharded]

JWT has been used from the origin of times, the very first 0.X conan version, 10 years ago.
The cypher of the JWT has also been there for years, even in Conan 1, maybe 6 years?

[mneumei]

And if i provide a token, it will store that token, correct? Is that behavior documented? i can´t find it in the documentation anywhere

[memsharded]

And if i provide a token, it will store that token, correct? Is that behavior documented? i can´t find it in the documentation anywhere

That behavior is server based, it depends on the server logic.
Conan always treat all inputs as "password", sends them as user-password, and retrieves a JWT token, treated as something different from the password.

If the server decides that the user password is actually already a valid token and returns that same token as JWT to the client, then that is a server side behavior.

[aagor]

At least for the SaaS JFrog Artifactory (https://<something>.jfrog.io), if I use either an access token (JWT) or reference token (cmVmd...) this gets stored directly in the .conan.db.

I guess, you could create a symlink to some tmpfs/ramfs (and something similar on Windows, not sure), if the database should not be stored on disk.

---

(And, in my personal opinion, the CONAN_LOGIN_ENCRYPTION_KEY should be fixed to provide proper security or removed:

conan/conan/internal/api/remotes/encrypt.py

Line 2 in 12e0cf9

# WARNING: These functions implements a Vigenere cypher, they are NO WAY OK FOR SECURITY!

The code comment is correct and no security is better than something that looks like secure, but actually is not.)

[memsharded]

At least for the SaaS JFrog Artifactory (https://.jfrog.io), if I use either an access token (JWT) or reference token (cmVmd...) this gets stored directly in the .conan.db.

Yes, but that is an internal Artifactory implementation detail, nothing we can do on the client side.

The code comment is correct and no security is better than something that looks like secure, but actually is not.)

Agree @aagor, lets remove it #20227

[memsharded]

Hi @mneumei

It would be great to understand better what are your concerns.
In general, this is not a big concern for reasons like:

• Conan cache is usually in <home>/.conan2 folder, including the secret. This is a safe, per-user folder, other users in the machine won't have access to it (if the attacker already has control of the machine for that user, then JWT token, won't be the most concerning thing)
• Typically, most developers only get read access to server repos. It is documented and strongly encouraged that only CI has write (upload) permissions to the server. Similar to the previous point, if the attacker already got access to the CI machine, then the problem is larger than getting the JWT token
• Passwords are not stored, only tokens

If you could please elaborate a bit more about the concerns or possible attack vectors, that would help a lot.

[mneumei]

Here are my concerns:

• this is not documented at all, so users don´t really know about that mechanism
• one risk is sharing your conan home folder (because why shouldn´t you?), and with that the secrets. JWTs would then give people access to the server, and even more information than a typical password. That the JWTs are encoded is i think a weak argument, as JWTs are pretty obvious and easy to decode - and using the API, i can get as many new ones as i want
• as a user, i don´t have a choice. Initially, i thought the auth remote plugin is used to authenticate my requests against the remote - this would be powerful as i could store my secrets the way i want them. But then i find it will only use that once, then store its own token - thats not really what i want

In general, documenting the whole authentication process on a single page would help, and having a plugin where you actually can provide the secrets would help even more

[memsharded]

Regarding "one risk is sharing your conan home folder (because why shouldn´t you?)"

Please check from https://docs.conan.io/2/knowledge/guidelines.html

 At the moment the Conan cache is not concurrent. Avoid any kind of concurrency or parallelism, 
for example different parallel CI jobs should use different caches (with CONAN_HOME env-var). 
This might change in the future and we will work on providing concurrency in the cache, but until 
then, use isolated caches for concurrent tasks.

So in general, sharing the Conan home folder should be avoided, because it can generate race conditions and other concurrency problems

That the JWTs are encoded is i think a weak argument, as JWTs are pretty obvious and easy to decode

That is true, we are removing the vigenere cypher, it doesn't really help, better remove it.

as a user, i don´t have a choice. Initially, i thought the auth remote plugin is used to authenticate my requests against the remote - this would be powerful as i could store my secrets the way i want them. But then i find it will only use that once, then store its own token - thats not really what i want

We will give this a thought, maybe the plugin can be extended or adapted to take into account this use case.