Encrypt crates.io API token under a password (optionally)

[tarcieri]

Originally from: rust-lang/crates.io#79

Right now crates.io API tokens are stored in the (presently chmod 644 i.e. world readable) ~/.cargo/config file under the [registry.token] section.

Storing credentials in plaintext, even if the file permissions were improved, still makes them vulnerable to local file disclosure (LFD) attacks. These attacks are exceedingly common, especially in environments where developers are running a number of services on their laptops and have not properly configured firewalls and/or service-specific security settings.

Encrypting credentials under a passphrase can help mitigate these attacks. SSH provides precedent for encrypting private keys under a passphrase.

Since cargo already depends on rust-openssl, I would suggest sourcing cryptographic primitives from there. AES-GCM with a password derived via PBKDF2 or as of OpenSSL 1.1.0, scrypt via the EVP_PBE_scrypt() API, which does not yet appear to be supported by rust-openssl (issue opened) should be sufficient to harden cargo API token storage against LFD attacks.

[alexcrichton]

👍

I'd prefer to avoid openssl for this (we don't use it on Windows), but I'm sure ring would be up to the task!

[tarcieri]

ring provides AES-GCM AEAD along with PBKDF2 at least (and I have a separate crate for scrypt) so... yes (also I'm already using ring for this purpose in other projects)

[epage]

With #12649 (will be released in 1.74), we now support credentials being supported in wincred, libsecret, and macos-keychain. However, I don't think we've done anything to make these the default when you cargo login. Is that right @arlosi ? Is this something can improve in the future, whether in cargo login and/or in documentation?

[arlosi]

We haven't made it the default. However, setting up a credential provider is required when using a private registry, which will also cause it to be used for crates.io tokens.

The documentation is here: https://doc.rust-lang.org/nightly/cargo/reference/registry-authentication.html

It may be worth adding a warning when doing cargo login if a credential provider hasn't been set up that links to the above docs.