Use constant-time comparison for rpcapd password hash verification

[kodareef5]

rpcapd/daemon.c line 1554 compares crypt() password hashes using strcmp(), which returns early on the first character mismatch. Replace with a constant-time XOR accumulation loop that examines all characters regardless of match position.

While crypt() dominates the overall timing, using constant-time comparison for authentication credentials is defense-in-depth best practice.

[infrastation]

Speaking of existing solutions to this problem, memcmp(3) refers to consttime_memequal(3), which is even shorter. More generally, it would be nice to find a way not to have to solve such problems in the first place, similarly to how git can work over SSH, but implements neither SSH nor the involved authentication.

[kodareef5]

Good point about consttime_memequal(3) — it's a cleaner solution where available. The challenge is portability: it's a NetBSD/OpenBSD extension, not present on Linux or macOS. We could add a configure check and fall back to the manual implementation, or use the manual version unconditionally for simplicity. Happy to go either way.

On the broader question — I agree that delegating auth to SSH is the better long-term model. But as long as rpcapd's password authentication path exists and is usable, the hash comparison in that path should be constant-time. Even if most users are on SSH, the code is still compiled and callable.

[guyharris]

To be precise, the comparison is constant-time in the "the time is padded so that shorter strings take the same time as longer strings", but the strlen() calls are O(N).

[guyharris]

"...and the comparison doesn't stop as soon as it knows that the strings aren't equal".

[guyharris]

Good point about consttime_memequal(3) — it's a cleaner solution where available. The challenge is portability: it's a NetBSD/OpenBSD extension, not present on Linux or macOS. We could add a configure check and fall back to the manual implementation, or use the manual version unconditionally for simplicity. Happy to go either way.

We could just take the NetBSD code and add it as rpcap/missing/consttime_memequal.c, and use that if the OS doesn't have it.

On the broader question — I agree that delegating auth to SSH is the better long-term model. But as long as rpcapd's password authentication path exists and is usable, the hash comparison in that path should be constant-time. Even if most users are on SSH, the code is still compiled and callable.

Yes, this is probably the right thing for now.

[guyharris]

Speaking of existing solutions to this problem, memcmp(3) refers to consttime_memequal(3), which is even shorter. More generally, it would be nice to find a way not to have to solve such problems in the first place, similarly to how git can work over SSH, but implements neither SSH nor the involved authentication.

Presumably on the server side a "git daemon", or whatever, is run as the ssh command run by the client, so the server doesn't need to implement SSH or authentication, the SSH daemon does; what does it do on the client side, e.g. in the git command?

[infrastation]

On the client side git does similarly, i.e. instead of implementing an SSH client git executes it. See GIT_SSH, GIT_SSH_COMMAND and GIT_SSH_VARIANT in git(1).