I think rust probably just needs some sort of dedicated infrastructure security team to sort these things out. I am not interested in arguing these things in such a way.
Someone should take ownership of developing a threat model for infrastructure and use that to answer questions like the ones posted in this topic. Bars should be set.
These conversations have reminded me why I much prefer getting paid for my work, at companies with systems in place for this sort of discussion to be had in a semi-sane manner. If a working group for this sort of thing existed, we could answer this by just addressing the existing threat model, discussing implementation, and working to understand the complexity involved. In fact, this would all be driven that way.
So thatās my suggestion. Start there. Pushing for security barriers without that is more painful than Iām willing to tolerate.
I like the idea of a security team! Rust is all about safe code, we should apply that up the chain too, to distribution. Iād be willing to help out in such a team.
Local machine compromise is a hard one to protect against. Hereās another attack:
Replace cargo binary with one that uploads tarball with malicious code added.
That binary can still ask for 2FA as usual. It can check all your tokens and ssh keys. Everything is authenticated, just uploads not what you expected.
Thatās just a notch more difficult to pull off than stealing of credentials file. 2FA is just a speed bump here.
opt-in is a shame and will have a lot lower impact, but I understand why they chose it - they're a huge repository with many more packages and maintainers.
No surprise that they went down the 2FA path, it's pretty obvious.
Whether or not you choose 2FA or something else, as a user Iād be more than happy having an email with a link I had to click on to make the publish happen as long as crates.io had a checkbox where I could turn that off should I need to (CI etc.).
Also that gives me the 30 seconds thinking time when I think āoh wait Iāve missed out Xā and can then quietly push out another version without anyone else realizing my omission.
Iām not anti-additional security on top of email, but email would be really a low friction startā¦ (and in that email you can encourage crate owners to have additional owners if truck number is too low)
(Also +1 to SMS 2FA not being secure)
For what it's worth the've had TOTP-based 2FA since last October. What appears to be new is the package-level flag which requires it for all publishers of that package.
Part of the point here is that without 2FA, there's no way I can intelligently make that decision. Even if I decide that I trust withoutboats, my decisions about failure aren't well informed - a bad actor shipping a malware update still looks like a withoutboats update. And cargo update -p failure will cheerfully install that update.
As an option that avoids making any changes to the CLI interface:
Have publish go to a staging area where only the author sees it on crates.io, and does a 2FA challenge to release it. This also allows for taking back an accidental publish as a side effect, as the publish isnāt public until you 2FA it.
This sidesteps problems around doing 2FA on the CLI and only requires trusting the browser. The small time disconnect also makes an attack harder as there are two surfaces that would have to both be compromised.
It also works perfectly with automated deployment: it goes to the staging location and you confirm it with āYes, I expected this publishā and 2FA.
2FA is about mitigating credential theft. If you want ironclad trust you need signing, not 2FA. And any security method is only as secure as the user makes it as any secret can be shared. You canāt just trust the system, you also have to trust the author and their tools.
Sorry, the decision was not to depend on crates which don't require 2FA to publish. So you wouldn't depend on failure if I don't have 2FA enabled.
(I'd also like us to retire the idea that 2FA is a silver bullet - "a bad actor shipping a malware update still looks like a withoutboats update" even if I have 2FA enabled, they just have to be able to generate 2FA codes, just like right now they have to steal my crates.io token.)
Iāve been working on a multi-provider digital signature library for Rust which (among other things) supports Ed25519 which is used in @withoutboats proposals:
It presently supports YubiHSM2s for Ed25519 hardware key storage.
Iām finishing up adding support for ECDSA with NIST P-256, which would allow usage of things like any PKCS#11 token (e.g. standard Yubikeys or other PIV tokens) or the OS X Keychain/SEP (possibly via security-framework).
All that said, using a memory hard PBKDF to derive a keywrapping key for a digital signature key which is decrypted in host memory and used to compute a signature on a package seems like a reasonable baseline to me which could work everywhere regardless of host OS, and can be implemented in pure Rust: something like argon2rs + miscreant + ed25519-dalek.
If signatures were required on packages, it would accomplish the same goals as what are proposed on this thread (requiring an additional authentication factor to publish packages) while also enabling a mechanism which could eventually be used for end-to-end package integrity.
I tend to agree with this view. It seems like managing the association of public keys to authors would be its own challenge, though, especially if we're concerned about accepting authentication as a crates.io responsibility.
Please donāt make 2FA mandatory. I think thatās not helpful, and harmful.
I begrudgingly enabled 2FA for my GitHub account because the rust-lang org enforces it. I donāt trust the security of my phone very much (too much proprietary stuff, too hard to update), so I donāt usually put anything trustworthy on it, but now my phone is involved in GitHub logins. I canāt see that as an improvement in security, though I have to admit it probably does not decrease security either.
It does, however, pose an additional barrier of entrance. Moreover, the information for how to do 2FA without relying on proprietary software is pretty sparse; GitHub itself only recommends proprietary apps (or, alternatively, wants to know my phone number) ā so I can just hope that the open-source app I picked from F-Droid is trustworthy. I consider installing proprietary software as decreasing the security of my device, so that wouldnāt have helped either.
I find it somewhat amusing that I can still log in using a password (a known-to-be-insecure authentication method) but then we paper over that using 2FA. Now that WebAuthn is becoming a thing, letās please just use key-based logins for everything that matters? I would consider a key-based login to GitHub, with a PW-protected key, to be way more secure than 2FA where one factor is just a password and the other is a phone.
I canāt help but feel that 2FA is hyped as a solution to problems caused by passwords, and frequently touted to be way more effective than it IMHO is.
GitHub supports U2F tokens as well, which are self-contained and provide much stronger authentication (challenge/response with public key cryptography). I'd strongly recommend getting one (or many) of them in general. Newer tokens support WebAuthn, which will be generally usable with Firefox (as opposed to things that depend on Chrome's weird u2f.js).
