Magic Wormhole is a security disaster. Do not use if you have other options.
1) By default, authentication key has only 16 bits of entropy. (I wish I was making this up…)
2) There's no good UI to make the key stronger: you can either use, say, "--code-length 16", which makes the receiving code ridiculously long, or provide your own code with "--code", in which case it's visible to other local users via ps(1).
3) Between "wormhole send" and "wormhole receive" on the other side, anyone on the Internet can attempt to intercept the transfer. Conveniently, you can list all currently valid channel ids (nameplates).
4) If the interception succeeds, the attacker can immediately run "wormhole send" with the same code, so that the intended side wouldn't notice anything is off.
5) If the interception fails, the attacker still ruined the transfer. (DoS)
All of this would be fixable, if not the maintainer's bizarre insistence on using weak crypto.
> By default, authentication key has only 16 bits of entropy. (I wish I was making this up…)
It's a PAKE being used for Socialist Millionaire-style interactive authentication. So that key needs to be successfully guessed by the attacker. If they guess wrong they don't get any further attempts, game over, all three participants (the sender, receiver and this attacker) learn it didn't work. That's just not an attractive attack.
I've written on HN before that I think this is too few bits on balance, but that's because of social effects (a million people use it, one person gets very unlucky, that impacts take up for the same reason people don't review products that were fine, they're either 5/5 best in class or 0/5 this product killed my cat)
Setting code length 16 means you want a 128-bit PAKE. You've noticed that 128-bit secrets aren't very convenient for humans. But you don't seem to have thought any further than that, just convinced it should be "fixable" without introspecting about the core problem.
> You've noticed that 128-bit secrets aren't very convenient for humans.
Meh. Even if you have to retype the secret, 128 bits in not a big deal. The time spent on typing is trivial in comparison to the time you're gonna waste when you fall victim to DoS. I'm speaking from experience.
1) By default, authentication key has only 16 bits of entropy. (I wish I was making this up…)
2) There's no good UI to make the key stronger: you can either use, say, "--code-length 16", which makes the receiving code ridiculously long, or provide your own code with "--code", in which case it's visible to other local users via ps(1).
3) Between "wormhole send" and "wormhole receive" on the other side, anyone on the Internet can attempt to intercept the transfer. Conveniently, you can list all currently valid channel ids (nameplates).
4) If the interception succeeds, the attacker can immediately run "wormhole send" with the same code, so that the intended side wouldn't notice anything is off.
5) If the interception fails, the attacker still ruined the transfer. (DoS)
All of this would be fixable, if not the maintainer's bizarre insistence on using weak crypto.