I fully agree with this, but I unfortunately have no more votes.
For users whose accounts have been compromised, it is absolutely essential that the 2FA recovery code be rotated. However, because of the lack of any UI elements for doing so, most users would not be aware that they need to rotate the code. In addition, as you have noted, it can be quite cumbersome to do so, even if one knows it should be done.
A clever attacker who has gained access to the vault of a user who did not have 2FA enabled would (after exfiltrating the vault contents) enable and then disable 2FA, after which they can copy the 2FA recovery code. When the user subsequently enables 2FA (without rotating the recovery code), the attacker will be able to use their copy of the recovery code to bypass the user’s 2FA.
At any point following enrollment, the subscriber MAY request a replacement recovery code
So, if Bitwarden desires to maintain NIST 800-63 compliance they will at some point need to implement this suggestion. I also think that the draft may cause a bit of a rethink because it states:
Account recovery is when a subscriber recovers from losing control of the authenticators … by presenting one or more recovery codes … Once this is completed, the subscriber can bind one or more new authenticators to their subscriber account.
In other words, I think the recovery code will change from removing MFA to instead logging into the two-step-login portion of the webvault.
But with the actual system (one single code that is invalidated when used), there would be the risk of permanent lockout if the user did not generate and save a new code right away after using it.
I don’t interpret the draft language in the way that you have. Note that it says “can bind” (emphasis added), not “must/shall bind”, and that the word “Once” does not imply “Immediately after”. Therefore, I think that the current behavior is already in compliance with the requirement quoted above.
I did not claim, nor do I believe that Bitwarden’s recovery mechanism is noncompliant with the draft language. Instead, I think that the draft foretells the direction of an evolution that the mechanism needs to take.
You, I and others have observed that the current mechanism (disable MFA) does not interact well with a future that requires MFA for device verification. The draft’s approach of offering a few different recovery mechanisms and focusing on reestablishing/repairing the 2nd factor seems to fit well with the that future.
That said, I did claim that the draft obliges Bitwarden to provide a way to rotate the recovery code. Although one may argue that using the code meets the requirement, that seems a bit disingenuous and per @kpris’s suggestion, I would hope the draft results in a dedicated button.
