Skip to content

infra: add policy covering mfa with hardware keys #1051

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ubiratansoares wants to merge 1 commit into
base: master
Choose a base branch
from
+71 −0
Open

infra: add policy covering mfa with hardware keys #1051

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 71 additions & 0 deletions src/infra/policies/mfa-critical-systems.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
# Multi-factor authentication in the Rust Project

The Rust infrastructure team adopts multi-factor authentication to secure access to different
systems, and in particular, it enforces stricter rules for services considered critical
Rust infrastructure.

## Multi-factor authentication and assurance levels

The Rust infrastructure team uses NIST's [Authentication Assurance Levels] to
score different MFA methods according to the security expectations they bring. Thus, we consider
as secure and approved MFA methods (in this order of preference):

1. Hardware security keys compatible with FIDO2 / Webauthn (e.g. YubiKeys) as AAL-3
2. Hardware enabled with Webauthn passkeys (e.g. Apple TouchId) as AAL-2
2. TOTP apps (e.g. Google Authenticator) as AAL-2

## MFA and critical infrastructure access

As a rule of thumb, when different MFA methods are supported by a service considered critical
infrastructure, Project members with *privileged* or *administrator* access **must** use the most
secure MFA method that the service provider supports. That means using hardware security keys whenever
possible, and if hardware keys are not an option, Passkeys or TOTP apps must be used otherwise.

Some of these services include:

- Google Workspace and GCP (`rust-lang.org`)
- AWS (through AWS SSO sessions)
- Azure
- Github
- Datadog
- Fastly
- Heroku
- 1password

The Rust Infrastructure team officially supports [Yubico YubiKeys Series-5] as AAL-3 tested and
approved devices. Project members may bring hardware keys from other vendors if they want, but
the Rust infrastructure team won't be able to offer support regarding bugs or compatibility issues.

In addition to that, when multiple secure MFA methods and devices are supported by a service, Project
members **should** configure at least one additional MFA method for redundancy purposes, as long as additional
MFA devices or methods are in the same AAL. For example, when setting up MFA for a `heroku` account, one may
configure additional YubiKey (AAL-3) for redundancy purposes, but **should not** configure `1password` as TOTP
Copy link
Copy Markdown
Member

@emilyalbini emilyalbini May 13, 2026 •
edited by rustbot
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think having a backup TOTP backup is inheritely a problem, as long as you store it offline/in a way that cannot be accessed during normal operations.

View changes since the review

Copy link
Copy Markdown
Contributor Author

@ubiratansoares ubiratansoares May 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with that. In the end, the policy is not mandating not having a TOTP backup, but I did not elaborate in which situation it could work just fine to not overcomplicate things. Happy to reframe a bit taking most of your own words. Happy to take a suggestion too :)

since this could potentially decrease security, especially if TOTP the backup is configured in a way that makes it reachable to attack vectors during admin operations.

(AAL-2) with the same intent, since this would decrease security.
Copy link
Copy Markdown
Member

@Mark-Simulacrum Mark-Simulacrum May 11, 2026 •
edited by rustbot
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that at least on GitHub AFAIK you can't disable TOTP if you ever added it, at least without talking to support. I know I'm in that bucket even though I have security keys now. It might be worth adding that to our discussions with them...

View changes since the review

Copy link
Copy Markdown
Contributor Author

@ubiratansoares ubiratansoares May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true. It's worth mentioning that it's possible to enforce only secure MFA on Github, which is something I'd arguee we want to do at somepoint, and kinda improve a bit things here

Copy link
Copy Markdown
Member

@Mark-Simulacrum Mark-Simulacrum May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that "secure MFA" inclusive of TOTP? So that wouldn't actually relate to this particular problem. (Not sure if GitHub allows removing SMS 2FA).

Copy link
Copy Markdown
Contributor Author

@ubiratansoares ubiratansoares May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not allow removing SMS 2FA, but only disabling it...

The secure MFA option will allow only TOTP apps as AAL-2, Github Mobile included.

screenshot-2026-05-11 at 16 41 49


Project members holding several hardware security keys **must** uniquely identify the ones used to access
Rust infrastructure, therefore guaranteeing non-ambiguity for the daily usage and revocation scenarios.
Copy link
Copy Markdown
Member

@Mark-Simulacrum Mark-Simulacrum May 11, 2026 •
edited by rustbot
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

guaranteeing non-ambiguity for the daily usage and revocation scenarios.

I don't understand what exactly we mean by this. Who are project members identifying these keys to? What kind of revocation or daily usage scenario are we talking about? I see you say below that they need to be revoked from all systems, but it's not obvious to me why that would require knowing the ID upfront (rather than auditing after the fact that only currently available keys are entered in the right systems).

View changes since the review

Copy link
Copy Markdown
Contributor Author

@ubiratansoares ubiratansoares May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand what exactly we mean by this. Who are project members identifying these keys?

Happy to clarify. The RF can grant two copies of each key for every eligible member who wants them. Eligible members are necessarily people with admin/privileged access to Rust infra. The extra key is intended to avoid people being locked out from accounts in case they loose access to the "main key" they keep around.

Hence, it's on Project members to identify the hardware keys they have around, and that could be as simple as having the "main one" in a keychain or similar.

What kind of revocation or daily usage scenario are we talking about?

For revokation, the important scenario is where a key (or device) gets lost or stolen, imho. For daily usage, it's most a praticality for people who already have personal keys and use them to access system like Github, it's on them to make it sure the spare keys we'll grant will be configured as a backup.

I see you say below that they need to be revoked from all systems, but it's not obvious to me why that would require knowing the ID upfront

When revoking a hardware key from a system there must be no ambiguity between the key it's been revoked and the one it's been kept, especially when someone just lost a key. Since one might have exactly the same models registered as MFA devices, it's one that person de-registering the correct device, avoiding being locked out of an acocunt by mistake.

That's mostly I tried to capture on these statements. Happy to rework them to make this idea more clear.


Finally, when a Project member with access to critical infrastructure loses access to a hardware device
used for MFA (e.g. a laptop was stolen or a YubiKey was lost), this must be disclosed with the Rust
Infrastructure team, and that device **must** be immediately revoked from all systems it was configured as
an allowed MFA device/method.

## Yubico Hardware Key grants

As part of the [Yubico Secure it Forward Program], The Rust Foundation will provide YubiKeys to Rust
Project members with critical infrastructure access. If you are eligible for such a grant and would
like to get the recommended YubiKeys for free, get in touch with the [T-infra team in Zulip].

The members of the following teams are eligible for this grant:

- `infra`
- `crates.io`
- `docs.rs`
- `release`
- `triagebot`
- `bors`

[Authentication Assurance Levels]: https://pages.nist.gov/800-63-3/sp800-63b.html#sec3
[Yubico YubiKeys Series-5]: https://www.yubico.com/products/yubikey-5-overview
[Yubico Secure it Forward Program]: https://www.yubico.com/why-yubico/secure-it-forward
[T-infra team in Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra
Loading