Host names hashing

Damien Miller djm at mindrot.org
Thu Jan 6 16:37:51 AEDT 2022


On Wed, 5 Jan 2022, Dmitry Belyavskiy wrote:

> Dear colleagues,
> 
> OpenSSH uses SHA1 without any alternate options for hostname hashing (looks
> like this is the last place where an alternate option for SHA1 is not
> available). SHA1 HMAC is considered safe enough for now, but it may change
> so it's definitely worth migrating to more safe algorithms (SHA2?).
> 
> I'd like to discuss possible options of such migration.

I'd prefer to remove hostname hashing. It's a pointless obscurity
measure, and the most it can ever offer is protection against casual
shoulder-surfing disclosure[*]

I wish I never added it. I consider it the most stupid thing I've ever
done to OpenSSH :(

As far as what a concrete migration plan would look like, maybe something
like:

1) Add an ObscureKnownHostnames option that, instead of hashing, simply
   base64-encodes the hostnames. This provides the same level of
   protection as the current option. Recommend this instead of
   HashKnownHosts in the manual.

2) (later) Add a deprecation warning to HashKnownHosts

3) (later still) Remove the HashKnownHosts option (or make it an alias
   to ObscureKnownHostnames)

4) (later again) Warn when known_hosts contains a hashed hostname

5) (finally) rip out the hostname hashing code entirely.

-d

[*] Any real adversary will be able to reverse the hash via a dictionary
or brute-force, since the entropy of hostnames is so small.

This cannot be fixed using usual methods (e.g. using a deliberately-slow
KDF like bcrypt or scrypt instead of a hash) because ssh needs to
consider every name in known_hosts and any KDF slow enough to present
a problem for an attacker will be far too slow to be invoked for every
name in the file, every time the user runs ssh.


More information about the openssh-unix-dev mailing list