[mikorym]

Can one mitigate for this attack by not storing any information about the salt?

Suppose there is a method x which creates a salt, but does not store it. Then, hash the IP a.b.c.d together with an output from method x. A user can perhaps specify an x of their choosing. Let's say the hash function is then of two variables g(x,a.b.c.d).

Would cracking g(x,a.b.c.d) necessary expose the workings of x? (Note that one may want to think of this as two functions and write g(f(x),a.b.c.d) instead. In such a case we are cracking f as a first step.)

In the article, one relies on the fact that step 1 exposes the salt and step 2 then exposes a.b.c.d.

[rocqua]

One might simply store a list of

   hash(address, Fingerprint)

Here we are essentially using the fingerprint of the server as the salt, which doesn't need to be stored locally.

This would mean you can't detect whether a host changed their fingerprint, just that you've never seen this host-fingerprint combination. So if someone were to MitM your box, you would need to be sufficiently surprised by the 'This is an unknown connection' warning to investigate further.

To actually detect changed fingerprints, you need to keep a list of IPs for which you know the fingerprint. As the list of viable IPs is so small, there is no way to obfuscate it. The only possibility would be to encrypt it, but that requires keeping some secret from your attacker.

[mikorym]

Thanks for this example.

[moviuro]

The salt has to be random, and stored locally.

You propose a new hashing algorithm that does: IP -> h. If the salt depends on the IP, you can create a rainbow table offline.

If you can generate the salt on the machine (on the fly), you need an algorithm that must run on the machine - what do you base that on? Hostname? local IP addresses? Hardware?... And known_hosts(5) can't be moved to a new machine anymore, as it's tied to a machine.

[mikorym]

I think what I have in mind is essentially a customisation option. And I think your answer (and others) does make a good case that there is not a more general solution to this at the moment (and not even conceptually).

As a custom solution there are many ways to solve this if we introduce a third parameter (such as simply encrypting your files with a password). I think however the point that many people are making is that the debate is about what the default should be, and without introducing a third factor.

The two step de-hash case (IP hash + salt) suggests interesting research topics on whether there are ways to have other combinations e.g.: (IP hash + x) or (IP hash + x + y) but with the assumption that we don't want any further apriori information. The point that you are making is that in fact we only have one variable (the IP) and the salt is simply a obfuscation step. Any other approach requires more parameters (hardware, fingerprints, etc.).