send --code does not verify that a nameplate was provided and uses the entire code as the nameplate instead

[afontenot]

This is almost certainly not intended behavior, as it voids security since the nameplate is not private.

One of the more obvious impacts here is that users are vulnerable to a malicious mailbox server, which is why I'm disclosing this publicly - the only real fix for an affected user is to stop sending codes that don't contain a nameplate.

Unfortunately, this is more dangerous than I originally thought, because the wormhole mailbox protocol has a list feature that makes all nameplates public.

./wormhole-rs send -v --code "xxxxxx" Cargo.toml

In debug log:

DEBUG magic_wormhole::core::rendezvous] Sending Claim(xxxxxx)

In Wireshark (unmasked websocket text):

0000   7b 22 74 79 70 65 22 3a 22 63 6c 61 69 6d 22 2c   {"type":"claim",
0010   22 6e 61 6d 65 70 6c 61 74 65 22 3a 22 78 78 78   "nameplate":"xxx
0020   78 78 78 22 7d                                    xxx"}

Code:

pub fn nameplate(&self) -> Nameplate {
    Nameplate::new(self.0.splitn(2, '-').next().unwrap())
}

splitn doesn't fail when there is nothing to split, so the next() just takes the whole string. Unfortunately Code is instantiated as a tuple struct, not by calling new, so it doesn't get checked that way either. The code also doesn't fail when doing PAKE, unfortunately, because the protocol uses the entire code (including the nameplate) as the password, so the fact that the code is 100% nameplate and 0% password is no bother. This part seems like a bit of a footgun for implementers.

[piegamesde]

Oh wow, I somehow had completely ignored that the protocol uses the entire code including the Nameplate for PAKE. I'll have a look into this.

The thing is, that nameplates technically do not need to be numeric, so it is not easy to do validation. Maybe the best thing would be to simply assert something about the length of the password?

Also, note that in what you describe codes like foo-bar would parse "foo" as nameplate and "bar" as password, which still has some password but with only half the entropy.

[afontenot]

I don't see any issue with allowing string nameplates. (Actually, you can even set the code to the empty string, and have it claim an empty nameplate with an empty password. I transferred a file this way with no issues.)

Also, note that in what you describe codes like foo-bar would parse "foo" as nameplate and "bar" as password, which still has some password but with only half the entropy.

That's a footgun for users to be sure. The biggest issue is that it's not obvious to the user what part of the code is nameplate and what part of it is password. That's actually how I discovered this bug, I was trying to figure out how MWRS handled that internally.

I think the cleanest way to do this might be to break with the Python client and have separate --password and --nameplate options. If the user doesn't provide a nameplate, pick one automatically like normal, but continue to use their custom password. This would create a cleaner break between the two.

Of course this might require more refactoring, and I'm not sure if breaking backward compatibility is an issue here.

Edit: to clarify, I'm not suggesting breaking with the protocol and only using the password portion for PAKE. I'm suggesting changing the CLI so that the nameplate and password portions of the code are provided separately by the user.