1. 7

  2. 5

    I’d love to see something generic like this. Any open port at the moment is subject to a load of attempts and it just takes one exploitable vulnerability in a server that holds any private data for everything to be lost. A mobile app that took an OTP key and did port knocking for a particular server would make it fairly easy to disable all inbound ports except for users who ran the right sequence.

    That said, port knocking is only really interesting because it lets something simple and (hopefully) easy to secure sit in front of the server process. Port knocking is about the simplest protocol that you can create and secure: the attacker either connects to a given port or doesn’t. To do it well, you need to listen on a lot of ports and block any remote that connects to the wrong one in the sequence. For example, reserve ports 1024 - 2048, listen on all of them, encode a one-time password as a sequence of 10-bit digits, where each port is one digit, and if a remote IP connects to any of the ports other than the next one in the sequence then block them. This is really hard to get right if two computers on the same IP try at the same time: you need to make sure that you track the remote IP and port (and hope that there aren’t any stateless NATs in the way that make sequential packets appear to come from different ports).

    It then opens up a lot. Any attacker on the same NAT’d network as the legitimate user (which can be a lot of users with carrier-grade NAT) can then attack your server. The real solution is probably to:

    • Aggressively privilege-separate your server applications, so nothing that an attacker can compromise can do anything bad.
    • Use strong credentials (SSH keys, client certs, WebAuthn, whatever) for client authentication, so that an attacker can’t brute-force client credentials.

    The second of these is increasingly possible. Most devices now come with an isolated key store: a TPM on most x86 PCs, the Secure Element on Apple devices, and either an isolated store or a TrustZone enclave (which is at least protected from the main OS) on Android devices, which offer signing services. These allow a live attack with a compromised client / client OS, but don’t let anyone extract the keys.

    Beyond that, Facebook is doing some interesting research on pattern recognition to ramp up security (I think others are now that they’ve published their initial work). For Facebook, ‘logged in’ is not a binary state. For low-value things, they let you in with just a password or cookie from an old login, but as you get to more sensitive bits of access they require more signal that you’re really you (which includes all of the creepy stalkerware that you’d expect from Facebook, such as ‘have you visited the same sites you normally do?’). I’d love to see something in Dovecot / NextCloud / whatever that would ramp up security if you were doing unusual searches or trying to download a lot of data and require two-factor auth then. None of these systems really have a good story for protecting users against a compromised client device.