Requiring 2FA to Publish to Crates.io

[withoutboats]

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.

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.)

[kornel]

I’ve got macOS Keychain working in Rust:

Add bindings for password functions

If Cargo used the Keychain, it’d make stealing of the login token much more difficult.

[nyarly]

Not everyone writes Rust on a Mac, though. That said, a limited set of alternatives might work.

[bascule]

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:

tendermint/signatory

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.

[nyarly]

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.

[RalfJung]

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.

[bascule]

now my phone is involved in GitHub logins. I can’t see that as an improvement in security

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).

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.

For an OSS mobile app for TOTP, check out https://freeotp.github.io/

[RalfJung]

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).

I haven’t heard of that before and will check it out, thanks!

EDIT: Oh, these are hardware tokens? Yeah that solves the “I don’t trust my phone”, but also significantly increases the barrier of entrance.

For an OSS mobile app for TOTP, check out https://freeotp.github.io/

I am now using andOTP, which (on a direct comparison) seemed to have the nicer user experience and (at least in F-Droid) more regular updates.

[dcao]

For some prior art: this blog post by Python dev Donald Stufft seems to have some info on the limits of package signing

[Finn]

Why not simply use the hash value of a crate. After reviewing that crate, the name+version and hash value is added to a whitelist. Such a system could be distributed, many people would reviewing crates independently and one could compute the intersection of whitelists. Or people could link to whitelists they trust, building a web of trust. Furthermore a factor could be stated, indicating how much someone trusts a certain crate or whitelist.

The pros is ultimate security. The cons is complications during development and debugging.

[Soni]

hmm. a blockchain with a block algorithm that only accepts crates.io-signed blocks and refuses to replace packages/versions would solve the MITM problem I think. without being power-hungry and without 51% attacks. altho it’s still hackable.

[bascule]

A simpler alternative to a blockchain is a transparency log like Certificate Transparency. Mozilla has done some work on applying this to the problem of binary transparency here:

https://wiki.mozilla.org/Security/Binary_Transparency

[nyarly]

I found this article unhelpful. While Stufft observes a number of real challenges in the space, at the root there’s a very common philosophy: “if it can’t be perfect, it’s not worth it.” They don’t present a solution, or argue that there isn’t a problem to solve.

Contemporary with this article was the beginning of TUF, which was being developed specifically to address the Python infrastructure - which is a bigger challenge, IMO, than Crates is. Since then, TUF has been adopted as the foundation of Docker Notary. It’s a solid approach that might be able to be applied wholesale.

[bascule]

While Stufft observes a number of real challenges in the space […] Contemporary with this article was the beginning of TUF

Yeah, he didn’t know about TUF at the time he wrote it, and later remarked that TUF addresses enough problems that it’s actually worth it:

Donald Stufft (dstufft)

[felix91gr]

Oh wow. Now that I’ve studied TUF a little bit, I think it’s amazing. Thanks for bringing it up, I’ve learned something really cool ^^

Coming back to the conversation: I think TUF might be a really good option. It assumes there will be compromise of keys, and works to mitigate whatever impact that could have. That’s really awesome.

If anyone wants to check TUF out, I’d recommend this video, which helped me a lot to really get the system.

[bascule]

Oh wow. Now that I’ve studied TUF a little bit, I think it’s amazing. Thanks for bringing it up, I’ve learned something really cool ^^

In case you missed it, there’s an open proposal to add TUF to crates.io here:

Issue: Security model / TUF

I’ve also been discussing a “minimum viable TUF” here:

New RFC: signing registry index commits

[Soni]

can’t you just MITM that? what stops someone from MITMing that?

[bascule]

can’t you just MITM that? what stops someone from MITMing that?

What stops someone from MitMing a CT log? CT logs are designed to be cryptographically verifiable (indeed the main use case is verifying X.509 certificates prior to opening TLS connections).

It carries a digital signature (i.e. a Signed Tree Head, or STH). To verify something is included in the log you need an inclusion proof (i.e. fragment of a Merkle tree) which is ultimately rooted in an STH. If there isn’t an inclusion proof for a particular binary, it isn’t trusted.

You can read more here:

How Log Proofs Work - Certificate Transparency

[Soni]

okay, so it’s basically equivalent but with single points of failure.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.